---
title: Hybrid Workforce Standard
version: "1.0.1"
label: "Candidate 1.0.1"
status: candidate
date: 2026-09-12
language: es
canonical: https://hybridwf.com/es/
author: Master Joe Phillips
author_url: https://masterjoephillips.com
license: CC-BY-SA-4.0
license_url: https://creativecommons.org/licenses/by-sa/4.0/
attribution: "Hybrid Workforce Standard de Master Joe Phillips, https://hybridwf.com/es/ — bajo licencia CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0/)."
disclosure: "The author also builds AIEmpl.com, a commercial platform in this category. This standard certifies no products and issues no seals."
---

# Hybrid Workforce Standard

**Un chatbot responde. Un copiloto ayuda. Un agente ejecuta una tarea. Un Empleado IA ocupa un puesto. La responsabilidad final sigue siendo humana.**

> No existen, como punto de partida, puestos humanos y puestos de IA. Existen trabajos que deben realizarse. Después se decide cuál es la combinación de recursos humanos y artificiales que produce el mejor resultado con el nivel correcto de riesgo, responsabilidad y control.

**Preámbulo.** La IA existe al servicio de propósitos humanos legítimos. La eficiencia no justifica degradar dignidad, agencia, derechos ni capacidad humana. Toda autoridad artificial permanece limitada, impugnable, reversible y subordinada a responsabilidad humana real.

**Por qué existe este estándar.** Este estándar es una declaración de independencia de la organización frente a la anarquía del prompt. Al exigir un contrato de rol, obliga a los líderes a pensar antes de automatizar.

**El objetivo estratégico.** Este estándar es el primer paso para cerrar la era de la «IA juguetera» y abrir la era del Empleado IA. Al adoptarse, moverá a las empresas desde un modelo de desarrollo de software, centrado en la herramienta, hacia un modelo de arquitectura social, centrado en la responsabilidad humana. — Master Joe Phillips

## Cómo citar

Cite las cláusulas por identificador, nunca por página ni número de sección. El texto de la cláusula es la unidad citable; las notas bajo cada cláusula son comentario y pueden revisarse entre versiones sin enmendar el estándar.

`Phillips, J. (2026). Hybrid Workforce Standard, Candidate 1.0.1, cláusula HWF-nn.`

```
Hybrid Workforce Standard de Master Joe Phillips, https://hybridwf.com/es/ — bajo licencia CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0/).
```

## Definición

> Un Empleado IA es un trabajador de software persistente y ligado a un rol, que ejecuta de forma autónoma responsabilidades empresariales recurrentes utilizando conocimiento organizacional y herramientas autorizadas, dentro de políticas y límites explícitos, manteniendo identidad trazable, desempeño medible, rutas de escalamiento y responsabilidad humana.

### El test de nueve propiedades

| # | Nombre | Definición |
| --- | --- | --- |
| 1 | Identidad persistente | Identidad operativa estable, rol, historial y separación por empresa o tenant. |
| 2 | Rol operacional definido | Misión, responsabilidades, resultados, exclusiones y expectativas de servicio existen en la operación. Escribirlas y versionarlas como AI Role Contract es lo que exige la conformidad; la propiedad se refiere a que el rol exista, no al documento que lo demuestra. |
| 3 | Contexto organizacional | Conocimiento de políticas, productos, clientes, personas y decisiones relevantes. |
| 4 | Herramientas y canales | Acceso autorizado a CRM, ERP, correo, calendario, tickets, bases de datos, APIs y comunicación. |
| 5 | Autonomía | Puede iniciar o continuar trabajo sin necesitar un prompt humano en cada paso. |
| 6 | Autoridad limitada | Permisos, umbrales de aprobación, presupuestos, acciones prohibidas y reglas de escalamiento. |
| 7 | Memoria gobernada | Contexto relevante entre tareas y en el tiempo, con procedencia, alcance y retención. |
| 8 | Observabilidad | Acciones, tool calls, costos, decisiones y resultados trazables. |
| 9 | Accountability humano | Un humano identificado, o cuerpo humano de gobierno, responde por configuración, controles, desempeño y excepciones, sin importar cuántos supervisores artificiales haya en el medio. |

El test es conjuntivo: un deployment califica como Empleado IA solo cuando las nueve propiedades están presentes. La presencia es binaria; la membresía la decide este test y nada más. La profundidad y la escala evolucionan, y la escalera de madurez describe esa evolución — nunca decide la membresía. Un sistema al que le falte cualquiera de ellas puede seguir siendo un excelente agente o automatización; llamarlo Empleado IA es una metáfora comercial más que una categoría administrativa verificable. La conformidad es una pregunta separada: las cláusulas obligan a los Empleados IA, y un deployment que las viola es un Empleado IA no conforme, no un no-Empleado IA — una definición que expulsara a los infractores dejaría al estándar sin nada que obligar. Y el test obliga en ambas direcciones: las nueve propiedades presentes en operación hacen del deployment un Empleado IA sin importar cómo se lo llame, con la carga de demostrar la no-calificación en el deployer (HWF-12).

### La escalera de vocabulario

| Término | Promesa principal | Comportamiento típico | Límite principal |
| --- | --- | --- | --- |
| Chatbot | Conversación | Responde preguntas | Espera prompts o inputs |
| Copilot / assistant | Aumentar al humano | Redacta, resume, sugiere | El humano sigue siendo el operador |
| Automation / RPA | Ejecución determinista | Corre flujos predefinidos | Frágil ante casos no previstos |
| AI agent | Acción orientada a objetivos | Razona, usa herramientas y ejecuta | Suele estar centrado en tareas u objetivos |
| AI teammate / coworker | Colaboración | Comparte contexto y ejecuta trabajo | Semántica organizacional variable según proveedor |
| Empleado IA | Custodia de un rol | Asume trabajo recurrente bajo gobierno | La categoría carecía de un estándar operacional compartido; este documento propone uno |

### Task execution frente a role stewardship

La frontera conceptual está entre ejecutar una tarea y custodiar un rol. Un agente puede ejecutar «envía estos veinte seguimientos». Un Empleado IA que ocupa el rol de SDR debe sostener el proceso recurrente dentro de límites definidos: identificar leads, investigar, contactar, seguir, registrar, escalar y reportar desempeño. La custodia no es propiedad: el puesto, su autoridad y su accountability tienen dueño humano. Lo que el recurso carga es la responsabilidad continua de sostener el proceso; lo que nunca puede cargar es la consecuencia.

**La IA ejecuta. La organización responde. Un humano gobierna.**

## Las cláusulas normativas

### Cómo leer este estándar

«Debe» marca un requisito: un deployment que lo incumple no conforma, sin importar cómo se lo llame comercialmente. En este estándar no hay cláusulas opcionales, porque un estándar corto y enteramente vinculante es más útil que uno largo y mayormente sugerido.

La conformidad es autodeclarada. Este estándar no certifica productos ni puntúa proveedores. Le da a una organización un test que puede aplicar a su propio deployment y publicar si así lo decide.

Una portada, cinco regímenes editoriales. Este documento contiene cláusulas normativas, lenguaje de conformidad, la doctrina WRM, el instrumento HWFA y los playbooks de transición. Cada uno carga su propia regla de cambio — el texto de cláusula solo se mueve por enmienda, las notas y la doctrina pueden revisarse entre versiones, el instrumento evoluciona con su evidencia — pero comparten un título, un número de versión y un archivo canónico legible por máquinas, porque un estándar que se recupera y se cita como unidad debe entregarse como unidad.

La edición en inglés se escribe con grafía estadounidense. Los nombres propios y los instrumentos citados conservan la grafía de su fuente, de modo que un instrumento citado aquí se lee como lo escribió su autor, y quien contraste la cita con el original encuentra las mismas palabras.

El texto de la cláusula es la unidad citable; cítela por identificador, o sea HWF-44 y no un número de página. Las notas son comentario y pueden cambiar entre versiones sin enmendar el estándar.

### El libro acompañante

Este documento es la especificación. Un libro acompañante cubre la práctica: cómo se diseña, se asigna, se gobierna y se retira un puesto en una semana ordinaria, y qué suele fallar primero. Se publica en inglés como AI Employee y en español como Empleado IA. La edición digital de cada uno se descarga gratis, igual que el estándar, y no pide nada a cambio: ni cuenta ni formulario.

No es normativo. Donde el libro y este estándar difieran, gobierna este estándar, y un claim de conformidad cita una cláusula, nunca una página. El autor escribió ambos, y eso se declara aquí por la misma razón que se declara la plataforma: usted debería saber quién gana con su lectura.

- [AI Employee. How to Design, Onboard, and Lead the New Hybrid Workforce](https://masterjoephillips.com/libros/ai-employee-en.pdf) — PDF, ISBN 979-8194133253
- [Empleado IA](https://masterjoephillips.com/libros/empleado-ia-es.pdf) — PDF, ISBN 979-8193784883

### La declaración de conformidad

Toda declaración de conformidad publica estos nueve campos (HWF-71). Una declaración a la que le falte cualquiera no es una declaración de conformidad bajo este estándar. El campo de clase de riesgo carga su razonamiento factor por factor, no solo la etiqueta. Y una declaración publicada es una representación comercial, accionable bajo el derecho del consumidor y de competencia: susténtela antes de publicarla, y retírela o corríjala oportunamente cuando venza o deje de ser válida.

1. Organización y deployment
2. Rol y versión del contrato de rol
3. Accountable owner
4. Clase de riesgo
5. Cláusulas evaluadas
6. Periodo de evaluación
7. Evidencia
8. Limitaciones conocidas
9. Fecha de expiración de la declaración

*«Este deployment de la Coordinadora de Cobros conforma con el Hybrid Workforce Standard, Candidate 1.0.1, para el alcance y periodo de evaluación declarados.»*

### 0 · Fundamento humano

#### HWF-01

**Las personas son fines; el software es un medio. La optimización de costo, velocidad o capacidad nunca debe pasar por encima de los derechos humanos, la dignidad, la seguridad, la agencia humana significativa, la accesibilidad ni las protecciones laborales aplicables. La neutralidad de recurso comienza solo después de satisfechas esas restricciones. Esta cláusula tiene precedencia sobre toda otra cláusula de este estándar.**

*Nota:* El motor de la organización híbrida es el costo, y este estándar no finge lo contrario: el desplazamiento va a ocurrir, como ocurrió con el tractor, y un documento que prometiera impedirlo sería ignorado y merecería serlo. Lo que un estándar puede hacer es lo que hizo la legislación laboral — gobernar los términos. Esta cláusula no prohíbe el desplazamiento: trabajo movido legalmente, con dignidad, dentro de las protecciones aplicables y a través de los playbooks de transición sigue siendo trabajo movido. Traza la línea entre desplazamiento y abuso, volviendo las restricciones léxicamente prioritarias: costo, velocidad y capacidad optimizan dentro del espacio que dejan abierto los derechos, la dignidad, la seguridad, la agencia humana significativa, la accesibilidad y las protecciones laborales, y nunca se intercambian contra ellos. Dos disposiciones ya apuntaban en esta dirección — el anti-KPI del Gerente de Fuerza Laboral Híbrida se niega a medir el rol por humanos reemplazados, y las compuertas duras del HWFA acotan la asignación sin importar la economía. Esta cláusula nombra la jerarquía que ambas obedecían. Su número no es su rango: obliga a toda otra cláusula, y un conflicto con cualquiera de ellas se resuelve a su favor. El linaje es explícito: los principios de IA humanocéntrica de la OCDE colocan la dignidad, la autonomía, la justicia social y los derechos laborales dentro de la definición de IA confiable, no junto a ella.

*Construida contra:* S24 · OECD — AI Principles (human-centred values: dignity, autonomy, social justice, labour rights)

#### HWF-02

**Ciertas decisiones están reservadas. Un recurso artificial nunca debe ser el único decisor en asuntos con efecto material sobre contratación, despido, disciplina o compensación; sobre salud y seguridad; sobre crédito, seguros o acceso a servicios esenciales; sobre derechos legales; sobre cualquier uso de la fuerza; o sobre el trato a personas vulnerables. Una decisión reservada es Crítica por definición, sin importar la clase evaluada del puesto. La reserva no excluye la participación artificial — el análisis, la redacción y la recomendación pueden delegarse. La decisión misma no, y una aprobación de un humano que no puede reformular el caso y decidir distinto es una firma, no una decisión.**

*Nota:* HWF-51 clasifica por juicio, y el juicio puede estar motivado: sin un piso, una organización bajo presión de costos clasifica las decisiones de despido como Moderadas y deja que la cola decida. Esta lista es el piso que ninguna evaluación puede bajar — los asuntos donde equivocarse cae sobre una persona y no sobre un libro contable. La segunda mitad de la cláusula existe porque el human-in-the-loop degenera por defecto: un aprobador frente a doscientas recomendaciones al día, cada una pre-puntuada y pre-redactada, aprueba a un ritmo que vuelve imposible entender, y el sesgo de automatización hace el resto. Eso no es supervisión; es la ceremonia de la supervisión. La prueba de una decisión real es operativa: el humano puede reconstruir los determinantes — HWF-41 existe para entregarle el material — tiene la autoridad y el tiempo para decidir distinto, y una decisión divergente no carga penalidad por defecto. Donde el ritmo de aprobación vuelve imposible reformular el caso, la organización automatizó la decisión y conservó una firma humana: responsabilidad perdida y no delegada, en términos de HWF-21. La lista interopera con el Artículo 22 del GDPR y los requisitos de supervisión humana del EU AI Act en la misma postura que la clasificación de riesgo — diseñada para viajar, sin afirmar equivalencia jurídica.

*Construida contra:* S26 · EU — GDPR Article 22: automated individual decision-making — S25 · EU — Artificial Intelligence Act: regulatory framework on AI (risk-based approach)

#### HWF-03

**Ningún puesto puede transformarse materialmente — automatizarse, pasar a humano asistido o dejar de serlo, revertirse a una persona o retirarse — sin una evaluación de impacto humano registrada, completada antes de que la transición comience. La evaluación debe nombrar a quiénes afecta y cómo: cambios en el trabajo, la autonomía y la vigilancia; el riesgo de deskilling; la carga intensificada de quienes absorben las excepciones; discriminación y accesibilidad; desplazamiento y reducción de personal; capacitación y reasignación; efectos sobre clientes y terceros. Los trabajadores afectados y sus representantes deben ser informados y consultados antes de la transformación, no después. La evaluación no está obligada a llegar a una conclusión favorable; está obligada a nombrar, medir y gobernar las consecuencias.**

*Nota:* Esto es HWF-01 con un instrumento. Una jerarquía de restricciones vale poco si nada la verifica en el momento en que se pone a prueba, y ese momento es la transición: el playbook tal como se escribió primero iba de baseline a handoff con las personas apareciendo una vez, como capacidad liberada, en el paso diez. La evaluación corre antes del paso uno. Dos de sus dimensiones merecen atención porque nadie las reporta voluntariamente. El deskilling es la silenciosa: la organización que automatiza su trabajo junior deja de producir seniors, y lo descubre el año en que los seniors se van. La carga de excepciones es la cruel: la automatización absorbe los casos fáciles y le deja a los humanos un flujo de puros casos difíciles, y luego los mide contra un throughput fijado en la era de los casos fáciles. La consulta es obligatoria y no es consentimiento: este estándar no otorga veto, y la ley laboral de cada jurisdicción puede otorgar más — la cláusula es piso, en la misma postura hacia el Artículo 26 del EU AI Act que el resto del documento, diseñada para viajar sin afirmar equivalencia jurídica. La última oración conserva la honestidad de HWF-01: una evaluación obligada a bendecir la transición sería teatro, y las consecuencias nombradas, medidas y gobernadas son la diferencia entre desplazamiento y abuso.

*Construida contra:* S27 · EU — AI Act Article 26: obligations of deployers of high-risk AI systems (worker information) — S33 · ISO/IEC 42005 — AI system impact assessment

#### HWF-04

**Una persona materialmente afectada por la acción de un Empleado IA tiene derechos frente al deployment: saber que intervino un sistema artificial; saber qué organización responde por él; obtener revisión de la decisión por un humano con autoridad para cambiarla; corregir los datos en que se apoyó; impugnarla; recibir una explicación comprensible de sus determinantes; y obtener reparación cuando la decisión fue incorrecta. La explicación debida es evidencia operacional — la política aplicada, los datos utilizados, las herramientas consultadas y la autoridad ejercida — nunca una transcripción de razonamiento, y se entrega a través de criterio humano: el material privilegiado o confidencial puede retenerse, toda retención se registra con su razón, y la confidencialidad puede estrechar una explicación pero nunca cancela el deber de dar una sobre la que la persona pueda actuar.**

*Nota:* Todas las cláusulas anteriores obligan a la organización hacia adentro; esta le da voz a la persona que recibe el efecto. Es barata para un deployment conforme, porque HWF-41 ya obliga a la organización a reconstruir estos determinantes para sí misma — la explicación es una traducción de un artefacto que ya debe existir, y la organización a la que estos derechos le salen caros está descubriendo que no cumplía HWF-41. La transcripción de razonamiento se rechaza por la misma razón por la que HWF-41 la rechaza como evidencia de auditoría, más una: entregada a una persona afectada, es una historia infalsificable vestida con la autoridad de una explicación. La evidencia operacional es disputable — una persona puede corregir un dato, impugnar una política, cuestionar un resultado de herramienta. Una narración no verificable no ofrece nada que se pueda impugnar, y la disputabilidad es lo que convierte los derechos de corrección e impugnación de palabras en mecanismos. Revisión significa revisión por un humano con autoridad para cambiar el resultado; cualquier cosa menor es otra vez el problema de la firma de HWF-02. La entrega corre por criterio humano porque ambos modos de falla son reales: los umbrales de fraude publicados son umbrales de fraude derrotados — la exposición adversarial es un factor que HWF-51 ya nombra — y una solicitud dirigida al Empleado IA se responde a través de la organización, porque «explícate» es también una superficie de extracción de prompt. El contra-candado impide que la excepción se trague el derecho: retener es la disciplina de HWF-35 volteada hacia afuera — legítima, con dueño, registrada, nunca silenciosa — y el piso es una explicación sobre la que la persona pueda actuar. La reparación sigue la ley de la jurisdicción; la cláusula es piso, e interopera con los Artículos 15 y 22(3) del GDPR y el Artículo 86 del EU AI Act en la postura de siempre del documento.

*Construida contra:* S28 · EU — AI Act Article 86: right to explanation of individual decision-making — S26 · EU — GDPR Article 22: automated individual decision-making

### 1 · La categoría

#### HWF-11

**Un Empleado IA debe ocupar un rol definido, no solamente una personalidad o un system prompt.**

*Nota:* El puesto existe antes que su ocupante. Un nombre, un tono y un conjunto de instrucciones describen una personalidad; un rol establece qué resultado debe producirse, con qué autoridad y medido cómo. Antes no significa congelado: un puesto puede ser remodelado por quien lo ocupa — Taylor fijaba a la persona a la caja, este estándar versiona la caja — y HWF-61 existe para que la remodelación ocurra como revisión declarada y no como deriva tácita.

*Construida desde:* doctrina propia WRM.

#### HWF-12

**No todo agente califica como Empleado IA. El umbral es la categoría misma: las nueve propiedades de la definición, exhibidas en operación. El test funciona en ambas direcciones: un deployment que exhibe las nueve propiedades en operación es un Empleado IA sin importar cómo lo llame la organización, y la carga de demostrar la no-calificación recae en el deployer. Las propiedades son hechos del deployment, no papeleo — un contrato de rol sin escribir es una falla de gobierno, no una salida de la categoría.**

*Nota:* Esta cláusula es lo que le da valor a la categoría. Si la etiqueta aplica a todo, no distingue nada. Una organización con veinte agentes excelentes y cero Empleados IA tiene claridad y no un problema — siempre que ninguno de los veinte exhiba las nueve propiedades en operación.

*Construida desde:* doctrina propia WRM.

#### HWF-13

**Humanos y Empleados IA pueden compartir un grafo operativo manteniendo condición y derechos distintos. Este estándar no reconoce personería, relación laboral, conciencia ni estatus moral en un sistema artificial, y no pretende resolver lo que sistemas futuros puedan ameritar: para los fines operativos y jurídicos actuales, un Empleado IA es un sistema de software no humano.**

*Nota:* Un organigrama compartido es una conveniencia administrativa, no una afirmación sobre mentes. No reconocer no es negar: la cláusula adopta la postura del derecho societario, que concede y retiene estatus jurídico sin pronunciarse sobre metafísica, y este estándar no afirma nada sobre lo que un sistema artificial es o podría llegar a ser en última instancia. No lo necesita. La dignidad, la salud, el descanso, los derechos laborales y la pertenencia se protegen aquí como propiedades de las personas — los trece principios exclusivamente humanos de la matriz — y cada cláusula de este documento se sostiene como sea que algún día se resuelva la filosofía de la mente, porque ninguna depende de la respuesta. Si esa pregunta alguna vez adquiere una respuesta que importe operativamente, atenderla es trabajo de una versión futura y su Board, no de deriva silenciosa en la presente.

*Construida contra:* S1 · Lattice — “Leading the Way in Responsible AI Employment” (9 Jul 2024) — S2 · SHRM — Lattice scraps plans to treat AI bots as employees after backlash (Jul 2024)

#### HWF-14

**Una identidad de IA nunca debe engañar. Las prohibiciones son resultados observables, no intenciones: hacerse pasar por humano; afirmar sentimientos, sufrimiento o experiencia personal; emitir señales razonablemente capaces de inducir una creencia falsa sobre lo que el sistema es o atraviesa; optimizar contra objetivos registrados la dependencia emocional o la explotación de la vulnerabilidad; y ocultar la intervención artificial en un punto material. La divulgación ocurre al inicio y se renueva cuando el sistema asume una función material. La cortesía, la empatía lingüística y la personalización siguen siendo legítimas mientras no afirmen interioridad.**

*Nota:* La antecesora de esta cláusula probaba el propósito: si una conducta existía para sugerir una mente con algo en juego. El diagnóstico detrás de esa prueba sobrevive; la prueba no, porque la intención es mal material de auditoría — nadie puede deponer el alma de una decisión de diseño, y un estándar cuyas demás cláusulas exigen evidencia operacional no puede conservar una cuya prueba sea leer mentes. La reemplazan dos estándares verificables. El estándar de efecto es objetivo: ¿una persona razonable, sabiendo lo que se ha divulgado, formaría una creencia falsa a partir de la señal? La latencia inyectada con indicador de tipeo falla — existe para leerse como una persona tecleando. Transmitir una respuesta larga por streaming en un contexto divulgado pasa, porque la única creencia que induce — que el sistema está produciendo texto — es verdadera. La divulgación resuelve qué es el sistema; no neutraliza las señales sobre qué atraviesa, y por eso la latencia inyectada, la vacilación actuada y los sentimientos declarados fallan el estándar incluso después de la divulgación: la creencia falsa que inducen es sobre la experiencia, no sobre la naturaleza (G-30). El estándar del objetivo registrado vuelve auditable el «deliberadamente» sin confesión: los blancos de optimización son artefactos — métricas de evaluación, objetivos de experimentos, funciones de recompensa — y son exactamente los determinantes que HWF-41 preserva, así que una auditoría lee qué se afinó el sistema para maximizar. Si el engagement se levantó con proxies de apego, el registro condena. El registro importa porque la tentación es estructural: un sistema al que se le optimiza el engagement puede encontrar en las señales de apego un camino corto, lo haya buscado alguien o no. Y una técnica que mejora la satisfacción porque quien lee cree algo falso es manipulación digan lo que digan sus métricas. Una función material es el momento en que la interacción deja de ser conversacional y se vuelve consecuencial — un pago, un compromiso, una confesión personal — y el deber de renovación sigue las obligaciones de transparencia del Artículo 50 del EU AI Act en la postura de siempre del documento: diseñada para viajar, sin afirmar equivalencia jurídica. El permiso final carga peso: la cortesía, la empatía lingüística y la personalización no afirman interioridad, y nada en esta cláusula exige que un Empleado IA escriba mal.

*Construida contra:* S30 · EU — AI Act Article 50: transparency obligations for AI interacting with people (Commission FAQ)

### 2 · Accountability

#### HWF-21

**Todo Empleado IA debe tener exactamente un accountable owner. La supervisión puede delegarse a otro Empleado IA; la accountability no. Toda cadena de supervisión termina en un humano o cuerpo humano de gobierno identificado. Uno es primario, no exclusivo: la accountability del owner no extingue las obligaciones distintas de un system owner, un controller de datos, un dueño de seguridad o compliance, un proveedor tecnológico o los directores legalmente responsables. Y donde el terminus es un cuerpo de gobierno, el cuerpo debe tener un presidente identificado, reglas de decisión declaradas y la capacidad de actuar en una emergencia.**

*Nota:* Supervisión y accountability son trabajos distintos y esta cláusula los separa. La supervisión dirige el trabajo: rutear, revisar, priorizar, recibir excepciones. Un recurso artificial puede hacerlo. La accountability es responder por el resultado, y eso exige capacidad de soportar una consecuencia jurídica, económica o reputacional. Una cadena de responsabilidad que termina en algo incapaz de soportar consecuencia no delegó responsabilidad: la perdió. Un Empleado IA puede recibir trabajo de muchas personas, pero la unidad de mando sigue aplicando: un recurso con dos dueños no tiene ninguno, y un recurso sin dueño queda huérfano administrativamente por bien integrado que esté. Exactamente uno responde la pregunta de quién responde por este recurso; nunca pretendió responder quién más tiene obligaciones. Un deployment carga un mapa de ellas — los deberes del controller de datos bajo la ley de privacidad, los de los dueños de seguridad y compliance, las responsabilidades contractuales y de producto del proveedor, la responsabilidad legal de los directores — y la unicidad de la ownership ubica el terminus operativo sin extinguir ninguna; HWF-23 ya rutea la culpa a los determinantes donde sea que estén en ese mapa. La oración del comité existe porque un cuerpo de gobierno sin presidente, reglas de decisión y capacidad de emergencia no es un owner sino un mecanismo de difusión: la responsabilidad de todos es la de nadie, y un cuerpo que necesita una reunión para actuar no puede sostener el poder de suspender que HWF-23 exige. El presidente no reemplaza al cuerpo; lo vuelve capaz de actuar entre sus propias sesiones, con ratificación posterior.

*Construida desde:* doctrina propia WRM.

#### HWF-22

**Una cadena de supervisión debe ser recorrible y observable de punta a punta. El humano o cuerpo accountable debe poder identificar a cada Empleado IA por debajo suyo, reconstruir cualquier acción ejecutada en su nombre, e intervenir en cualquier punto de la cadena sin pasar por ella.**

*Nota:* Intervenir sin pasar por la cadena es la parte que sostiene todo. Si detener a un Empleado IA tres niveles abajo exige pedírselo al que está encima, quien responde tiene una petición y no control. La profundidad no está prohibida ni se fija un límite aquí, porque el límite real es el span of control: un principio que este marco clasifica como adaptado y no como abolido, o sea que la escala puede crecer pero solo contra tooling, dashboards y límites de supervisión que hagan gobernable ese crecimiento. Un solo humano nominalmente accountable por mil Empleados IA repartidos en seis niveles, sin un instrumento capaz de mostrar qué hizo cada uno, tiene un organigrama y no accountability. Describir esta arquitectura no es endosarla: el estándar dice qué debe seguir siendo cierto si una organización la construye.

*Construida desde:* doctrina propia WRM.

#### HWF-23

**La accountable ownership es una capacidad dotada de recursos, no un nombre en un campo. El accountable owner debe tener competencia sobre el dominio, autoridad efectiva, tiempo y capacidad para el alcance que supervisa, acceso directo a la evidencia, independencia suficiente de las presiones que son dueñas del resultado, el poder de suspender el recurso, y entrenamiento sobre sus limitaciones y sobre el sesgo de automatización. El mecanismo de suspensión debe ejercitarse con una cadencia declarada — nunca mayor a doce meses, y más corta para puestos Altos y Críticos: un mecanismo de suspensión no ejercitado no constituye un control operativo efectivo. La accountability no debe descargarse sobre el humano que supervisa: donde los determinantes de una falla llevan a la política, el diseño, el tooling o el deployment, la responsabilidad aterriza ahí, y un humano colocado al final de un proceso no es una zona de absorción para culpa que pertenece aguas arriba.**

*Nota:* La nota de HWF-22 ya había nombrado la falla: mil Empleados IA sin un instrumento capaz de mostrar qué hizo cada uno son un organigrama y no accountability. Esta cláusula declara las condiciones que vuelven real la ownership, y dos merecen atención. La independencia es la filosa: un dueño cuyo bono depende del throughput que el recurso produce enfrenta un conflicto que ninguna buena intención resuelve, y no debe ser la única autoridad de suspensión — la supervisión y la presión de resultado deben separarse, que es la separación de funciones de HWF-33 elevada al nivel del rol. Tiempo y capacidad es la silenciosa: el span of control es un principio adaptado, así que la escala solo crece contra tooling — la titularidad nominal sin capacidad de supervisión no constituye control efectivo. El ejercicio de suspensión es la disciplina del simulacro de incendio: ejercitado con cadencia declarada y registrado, donde una falla descubierta en ejercicio es un hallazgo y una descubierta en producción es un incidente — la primera activación real no puede ser la primera activación. Dicho sin rodeos: un kill switch que nunca se ha jalado es decoración. La prohibición de zona de absorción toma su nombre del estudio de Elish sobre cómo la culpa en sistemas automatizados aterriza en el humano más cercano mientras el control estaba aguas arriba, y su mecanismo de HWF-41: la culpa sigue a los determinantes, no a la proximidad. El humano que supervisa responde por lo que controló — su revisión, su intervención — y lo que no podía controlar aterriza en quien lo poseía. Esto además completa HWF-21 desde el otro lado: portar una consecuencia exige haber tenido control, y consecuencia sin control no es accountability sino chivo expiatorio — un rol que ninguna persona competente aceptaría, que es exactamente por lo que la prohibición protege al dueño tanto como protege la verdad.

*Construida contra:* S29 · Elish — Moral Crumple Zones: Cautionary Tales in Human-Robot Interaction (2019)

### 3 · Autoridad y control operativo

#### HWF-31

**La autoridad debe ser explícita, limitada y revocable.**

*Nota:* Lo que el recurso puede decidir sin aprobación debe estar escrito antes de que opere, no inferido después a partir de lo que resultó haciendo.

*Construida desde:* doctrina propia WRM.

#### HWF-32

**El acceso debe cumplir least privilege.**

*Nota:* El contexto es capacidad, pero también es superficie de riesgo. Más acceso no es más competencia; es un blast radius mayor.

*Construida desde:* doctrina propia WRM.

#### HWF-33

**Las acciones de alto riesgo deben soportar aprobación humana.**

*Nota:* La regla es proporcionalidad: a mayor costo del error y menor reversibilidad, más aprobación soporta la acción. Aplica separación de funciones, así que quien inicia no necesariamente aprueba. Qué cuenta como alto riesgo no queda al gusto: se resuelve contra la clasificación de riesgo de HWF-51.

*Construida desde:* doctrina propia WRM.

#### HWF-34

**El sistema debe saber cuándo escalar en vez de improvisar.**

*Nota:* Un recurso que produce una respuesta convincente en vez de escalar una duda es más peligroso que uno menos brillante pero mejor gobernado. Toda excepción necesita un destino — y ninguna métrica puede castigar el viaje: un sistema medido por escalar menos aprende silencio, así que la escalación se juzga por el par perdidas-versus-innecesarias del scorecard del Gerente de Fuerza Laboral Híbrida, nunca por volumen a solas.

*Construida desde:* doctrina propia WRM.

#### HWF-35

**El aprovisionamiento de contexto debe ser deliberado en ambas direcciones. Retenerle contexto a un Empleado IA es una decisión de diseño legítima, sea para proteger la información o para prevenir la degradación medible de la decisión — anclaje, contaminación de contexto, saturación; no es una omisión y no debe tratarse como tal. Toda restricción debe registrarse en el contrato de rol como un registro de frontera de contexto, versionarse como cualquier otra autoridad, y estar disponible para la auditoría. La responsabilidad por una decisión degradada por contexto retenido recae en quien lo retuvo.**

*Nota:* La justificación de riesgo siempre estuvo: el contexto se divide en debe saber, puede consultar y no debe acceder desde el primer borrador. Lo que faltaba era la segunda razón para restringir. Un recurso que ve todas las disputas anteriores se ancla en ellas; uno que lee el último diagnóstico lo hereda; uno al que se le entrega todo lo relevante ahoga la señal en lo meramente relacionado. El anclaje, el sesgo de confirmación y la sobrecarga operativa son degradaciones de la decisión y no fugas de información, y un manager que lee una cláusula de solo-riesgo no tiene motivo para retener nada que no sea sensible. El registro es el precio de la herramienta, porque la opacidad deliberada es, sin él, el instrumento perfecto para lavar accountability — «el sistema no tenía ese contexto» es el descendiente nativo de IA de «a mí nadie me avisó». Una restricción escrita, versionada y auditable es diseño; la misma restricción sin documentar es una defensa preparada de antemano, y la última oración de la cláusula le quita esa defensa. Nada de esto legitima privar al recurso del contexto que su rol necesita: retenerle el que requiere para escalar bien no es opacidad sino sabotaje del HWF-34.

*Construida desde:* doctrina propia WRM.

### 4 · Evidencia y datos

#### HWF-41

**Toda acción material debe ser auditable, y la auditoría debe reconstruir los determinantes de la decisión además de su resultado: la política, el conocimiento, los resultados de herramientas, la autoridad y las versiones vigentes al momento de ejecutarse la acción. El relato que el propio modelo haga de su razonamiento puede apoyar esa reconstrucción pero nunca la sustituye. Qué cuenta como material lo fija la clase de riesgo del puesto: de Alto hacia arriba los determinantes se atan a cada acción, y para puestos Bajos y Moderados, correlacionar event logs contra el manifiesto de versiones de HWF-43 es reconstrucción conforme.**

*Nota:* Actor, input, herramienta, acción, aprobación, resultado y timestamp dicen que algo pasó. No dicen por qué, y sin el porqué una organización no puede atribuir una falla a su causa: una política equivocada, un conocimiento que envejeció, una herramienta que devolvió datos malos, un modelo que erró, o un rol que nunca debió asignarse a un recurso artificial. Esos cinco exigen remedios distintos y dejan registros idénticos bajo una auditoría de solo-qué. La cláusula que más protege es HWF-34: con solo el resultado se ve que el sistema respondió, nunca que debió dudar. El material ya está exigido en buena parte en otro lado — HWF-42 gobierna la procedencia de lo que el recurso sabía, HWF-43 las versiones de modelo, política, herramientas y knowledge base — así que lo que esta cláusula agrega es la obligación de ligarlas a una acción concreta en vez de sostenerlas como inventario general. El razonamiento declarado por un modelo es admisible como evidencia de apoyo y no es prueba de causa: lo que un sistema reporta haber pensado puede no ser lo que produjo su salida, y una organización que tome esa narración por el porqué va a escribir postmortems confiados y equivocados. Cuando se retengan trazas de razonamiento, su alcance, retención y borrado caen bajo HWF-42 como cualquier otra memoria, porque suelen contener datos de clientes recuperados.

*Construida desde:* doctrina propia WRM.

#### HWF-42

**La memoria es un sistema de datos entre varios, y el gobierno los cubre todos: inputs, outputs, resultados de herramientas, memoria y las inferencias derivadas de ellos. Cada uno debe tener finalidad y base legal declaradas, minimización, controles de calidad y actualidad, manejo de datos sensibles, reglas para transferencia internacional y para cualquier uso por el proveedor — entrenamiento incluido — aislamiento por empresa, y eliminación verificable. Y el registro de auditoría es él mismo uno de estos sistemas: los registros guardados para reconstruir decisiones pueden vigilar a los empleados y clientes que aparecen en ellos, así que los logs se gobiernan con la misma severidad que la operación que auditan — integridad protegida, acceso controlado, finalidad acotada.**

*Nota:* Recordar mejora el desempeño y crea exposición al mismo tiempo. Una política sin fecha produce respuestas consistentes y equivocadas; una excepción histórica no debería convertirse en regla en silencio. El alcance ampliado existe porque la superficie de datos del deployment nunca fue solo la memoria: los prompts cargan confesiones de clientes, los resultados de herramientas cargan datos de cuentas, los outputs cargan decisiones, y una inferencia — este cliente probablemente está en apuros financieros — es un dato fabricado sobre una persona que nunca lo entregó, gobernado como si se hubiera recolectado y con frecuencia más sensible que todo lo que sí se recolectó. El uso por el proveedor se nombra porque es el canal silencioso: los datos pueden salir por el pipeline de entrenamiento del proveedor del modelo sin dejar rastro en los sistemas propios de la organización, así que la regla debe ser contractual y declarada — y es una afirmación que una declaración de conformidad puede cargar. Una eliminación que no puede evidenciarse es retención con pasos extra. La oración de los logs cierra un circuito que este estándar abrió solo: HWF-41, HWF-22, HWF-71, HWF-04 y HWF-23 engordan cada una un archivo donde aparecen empleados y clientes — quién dijo qué, quién aprobó qué, quién tardó en intervenir — y cuanto más conforme el deployment, más rico crece ese archivo. Su propósito es la reconstrucción y la accountability; minarlo para puntuar empleados o perfilar clientes es un propósito nuevo que exige su propia base, y una organización que convierte su aparato de seguridad en aparato de vigilancia envenena el incentivo de loggear honesto. HWF-03 ya lista la vigilancia entre sus dimensiones de impacto; esta cláusula gobierna su fuente nueva más grande.

*Construida contra:* S31 · EU — GDPR Article 5: principles relating to processing of personal data

#### HWF-43

**Un Empleado IA debe tener una versión identificable de modelo, políticas, herramientas y knowledge base.**

*Nota:* Sin versionado es imposible saber qué autoridad existía en un momento dado, ni qué cambio produjo una mejora o un deterioro.

*Construida desde:* doctrina propia WRM.

#### HWF-44

**El desempeño debe medirse por outcomes, calidad, riesgo y costo — nunca por actividad, horas, tokens o cantidad de mensajes.**

*Nota:* La velocidad hace que la actividad parezca valor. Un proceso mal diseñado que producía diez errores producirá cien al automatizarse, y el dashboard lo llamará productividad.

*Construida desde:* doctrina propia WRM.

### 5 · Riesgo y validación

#### HWF-51

**Todo puesto de Empleado IA debe portar una clase de riesgo declarada de la escala de este estándar, evaluada dos veces: riesgo inherente antes de los controles y riesgo residual después de ellos. La clase sigue al riesgo inherente — los controles bajan el residual, nunca la clase. La autonomía, la supervisión y los requisitos de aprobación escalan con la clase; una acción Crítica termina siempre en una decisión humana final, y un uso Prohibido no puede volverse conforme mediante ningún control.**

*Nota:* La clase responde el término abierto de HWF-33: qué cuenta como alto riesgo se resuelve contra esta escala y no contra el gusto. El juicio corre sobre siete factores — derechos afectados, escala de personas alcanzadas, reversibilidad, presencia de personas vulnerables, sensibilidad de los datos, exposición adversarial y concentración de poder — nunca sobre el costo del error a solas, porque un error barato a escala contra personas vulnerables no es un error barato. El candado del texto citable existe por una razón: sin él, toda conversación con un vendor se convierte en «le pusimos un guardrail, así que ahora es Low». Los controles ganan un mejor residual; no compran una mejor clase. El HWFA deriva una clase provisional de costo del error y reversibilidad al asignar; la clase declarada de esta cláusula pesa los siete factores y prevalece, y Prohibido no es un output del instrumento sino una precondición — el HWFA pregunta quién debe ejecutar un uso, y un uso Prohibido no tiene quién. Los niveles están diseñados para interoperar con regímenes basados en riesgo como el EU AI Act sin afirmar equivalencia jurídica: mapear una clase a una categoría legal es un ejercicio de abogados, no una propiedad de este documento.

*Construida contra:* S25 · EU — Artificial Intelligence Act: regulatory framework on AI (risk-based approach)

#### HWF-52

**Una versión es un registro, no una prueba. Todo cambio material a un deployment — modelo, herramientas, políticas, conocimiento o autoridad — debe revalidarse antes de operar, a una profundidad fijada por la clase de riesgo: casos representativos, rutas de excepción y escalamiento, y regresión contra el baseline anterior; de Alto hacia arriba, pruebas adversariales contra inyección y exfiltración, análisis de sesgo y monitoreo de drift. Donde los Empleados IA trabajan en equipo, los riesgos sistémicos son parte de la validación: delegación circular, feedback loops, contaminación de memoria, falla correlacionada sobre un mismo modelo o proveedor, y propagación lateral de autoridad.**

*Nota:* La batería de pruebas presupone un sistema estocástico — algo que razona, y que por tanto puede driftear, alucinar y ser inyectado. La automatización determinista no hace nada de eso, y nada de esta cláusula la tocó jamás: la automatización está peldaños debajo de Empleado IA en la escalera de vocabulario y falla el test de nueve propiedades, así que las obligaciones se atan a la categoría y la categoría excluye el determinismo. La automatización determinista no presenta los riesgos de deriva propios de un sistema estocástico, de modo que exigirle ese monitoreo no mide nada. Entre Empleados IA el dial es la clase de riesgo, no el todo-o-nada: un deployment de riesgo Bajo revalida casos, excepciones y regresión, y la batería adversarial y de sesgo llega de Alto hacia arriba, porque HWF-51 existe precisamente para que las obligaciones escalen. La cláusula cierra una asimetría que el estándar cargaba: el nacimiento está exquisitamente compuertado — doce pasos, shadow mode, performance gate, una transición ganada con evidencia — mientras el cambio no tenía compuerta alguna, y un swap de modelo podía llegar a producción sin probarse. Los doce pasos ganan la transición; esta cláusula la mantiene ganada. Los riesgos de equipo existen porque HWF-22 permite pirámides: la delegación puede circular, el feedback puede componerse, la memoria puede contaminar el contexto aguas abajo, la autoridad puede propagarse lateralmente por los handoffs — y el riesgo menos intuitivo es la falla correlacionada. Los equipos humanos tampoco fallan de forma independiente, pero la diversidad de experiencia y criterio tiende a distribuir algunos puntos ciegos; las instancias que comparten modelo, proveedor, contexto o configuración los concentran. El precedente es la falla de causa común, conocida desde hace décadas en ingeniería de confiabilidad; lo nuevo es la velocidad, el alcance y la opacidad con que se propaga. La diversidad y el fallback son su mitigación. Sobre el método, este estándar dice qué debe validarse y cuándo; ISO/IEC 42001 y 42005 y el NIST AI RMF aportan sistemas de gestión para el cómo, y este documento los complementa en vez de recrearlos — la misma subsidiariedad que aplica al derecho laboral.

*Construida contra:* S14 · NIST — AI Risk Management Framework — S32 · ISO/IEC 42001 — Artificial intelligence management system — S33 · ISO/IEC 42005 — AI system impact assessment

### 6 · Ciclo de vida

#### HWF-61

**Un contrato de rol debe ser revisable y debe revisarse con una cadencia declarada, nunca mayor a doce meses. La divergencia entre los outcomes medidos y la misión, autoridad o KPIs declarados debe detectarse por monitoreo independiente contra el contrato — el control primario — y cuando los propios datos de desempeño del Empleado IA la muestren primero, el recurso debe reportarla al accountable owner como hallazgo: una señal que complementa el monitoreo independiente, nunca lo reemplaza. La decisión de cambiar un contrato de rol es siempre humana y le corresponde al accountable owner; nunca la toma un supervisor artificial y nunca se aplica automáticamente. Toda obligación con reloj sobre un puesto — revisiones, re-justificaciones, renovaciones, simulacros y revalidaciones — aparece en un único calendario de gobernanza en el contrato de rol, con un solo dueño con nombre del cronograma.**

*Nota:* El defecto más común de un contrato de rol no es que esté mal escrito. Es que nadie lo miró desde el día del deployment, mientras los productos, las políticas, los clientes y los patrones de excepción se movieron todos. El recurso está más cerca del trabajo que su dueño y ve la divergencia primero, así que exigirle que reporte lo que sus propios datos muestran cuesta poco y evita la deriva silenciosa — aunque un recurso cuyo modelo o configuración son el problema comparte el punto ciego, y por eso la cláusula hace del monitoreo independiente el control primario y del auto-reporte un complemento. Un hallazgo no es una petición: un Empleado IA no tiene intereses reconocidos que defender, y tratar su reporte como una negociación reintroduciría exactamente la confusión que HWF-13 existe para impedir. La decisión sube siempre a un humano, y nunca al supervisor artificial que tenga encima, porque un sistema capaz de ampliar su propio alcance a través de otro sistema no tiene un alcance acotado.

*Construida contra:* S11 · CIPD — Performance Management factsheet

#### HWF-62

**Toda transición entre tipos de ocupante — humano, humano asistido o artificial — y todo paso hacia o desde automatización determinista debe poder evaluarse contra un baseline y tener criterios de rollback explícitos.**

*Nota:* Sin un baseline registrado antes del cambio, la organización puede celebrar una mejora que nunca ocurrió. Criterios de rollback escritos después de conocer los resultados no son criterios; son justificación.

*Construida desde:* doctrina propia WRM.

#### HWF-63

**Un puesto de Empleado IA no debe sobrevivir a su justificación. Con una cadencia declarada, nunca mayor a doce meses — y de nuevo dentro de una ventana declarada tras todo cambio material de estrategia, política, regulación, producto o estructura —, el accountable owner debe re-justificar la existencia del puesto frente a la estrategia vigente, una pregunta previa y separada del desempeño, porque un recurso puede cumplir todos sus KPIs en un puesto que la organización ya no necesita. La re-justificación debe considerar si un alcance modificado mantiene vigente el puesto antes de concluir su retiro; un alcance modificado se re-justifica por sus propios méritos y nunca hereda la justificación anterior, y el trabajo inventado para preservar un puesto es una justificación fallida, no un rediseño. La continuidad nunca es el default: un puesto cuya existencia no puede re-justificarse pasa a retiro, y sus accesos terminan con él. Una revisión vencida no es una revisión reprobada: escala al accountable owner y restringe o suspende el puesto en proporción mientras se fuerza la revisión — el retiro es el resultado de una justificación fallida, nunca de un calendario perdido.**

*Nota:* Las presiones humanas de poda son débiles y fallan seguido — las burocracias cargan puestos muertos por décadas. Pero existen: una línea de salario que una revisión de presupuesto cuestiona, un ocupante que se va y fuerza la decisión de reemplazo. Un puesto artificial elimina hasta esos disparadores débiles — su costo se fragmenta entre cómputo, integración, supervisión, datos e incidentes, y rara vez aparece como una línea que alguien deba defender; y nadie renuncia jamás de él — así que un puesto sin sentido no solo persiste por defecto; pierde las últimas ocasiones en que alguien lo notaría. En la propia clasificación de este marco, eso convierte a la poda organizacional en un principio adaptado: un mecanismo que ya era poco confiable para humanos desaparece por completo para ocupantes artificiales, y esta cláusula es el reemplazo. Lo que se acumula sin ella es deuda organizacional, y su forma más peligrosa es el zombi digital: credenciales, accesos a datos y autoridad vigente mantenidos vivos para trabajo que nadie necesita — con HWF-32 en mano, superficie de riesgo sin retorno. La pregunta de existencia va antes que la de desempeño porque una buena respuesta a la segunda es el anestésico habitual contra la primera. La cadencia pertenece al contrato de rol, y el techo de doce meses del texto citable es un máximo y no una recomendación: los puestos de alto volumen y alto riesgo merecen menos. Esta revisión puede compartir calendario con la de HWF-61; nunca debe compartir su default. El calendario solo no alcanza: un puesto puede quedar desalineado el día después de un cambio de rumbo y esperar once meses a que le toque, y por eso la cláusula añade un disparador por evento. Y el orden de la revisión importa tanto como su frecuencia. Preguntar primero qué habría que modificar es lo que hace cualquier organización competente con un puesto humano cuando cambia la estrategia, y se traslada al ocupante artificial por economía y no por compasión: el contexto provisionado, la memoria gobernada, las integraciones, la calibración y la confianza construida alrededor del puesto son caros de reconstruir, y reconstruir suele costar más que adaptar. El candado contra el abuso de esa postura está en el texto citable — un alcance modificado no hereda nada, e inventarle trabajo a un puesto para mantenerlo vivo es exactamente la falla que la cláusula existe para nombrar.

*Construida desde:* doctrina propia WRM.

#### HWF-64

**El offboarding debe revocar accesos y transferir o destruir contexto de forma segura.**

*Nota:* Revocar credenciales, deshabilitar herramientas, detener schedules y colas, rotar secretos, transferir trabajo pendiente, preservar evidencia. El offboarding es tan importante como el onboarding y casi siempre se omite.

*Construida desde:* doctrina propia WRM.

### 7 · Conformidad

#### HWF-71

**La conformidad pertenece a un deployment, nunca a un producto, una plataforma ni una organización en abstracto. Una declaración de conformidad debe nombrar su alcance — la organización y el deployment, el rol y la versión del contrato de rol, el accountable owner, la clase de riesgo, las cláusulas evaluadas, el periodo de evaluación y su expiración — y debe publicar su evidencia y sus limitaciones conocidas. Un proveedor puede declarar que su plataforma habilita deployments conformes; nunca puede declarar que la plataforma misma conforma, y el claim de habilitación exige al menos una declaración viva y no vencida de un cliente, enlazada públicamente. Una declaración de conformidad con el estándar evalúa todas sus cláusulas; algo más estrecho se rotula conformidad parcial y nombra las cláusulas evaluadas. Ninguna declaración es válida por más de doce meses.**

*Nota:* La conformidad autodeclarada sin unidad definida degenera en frase de marketing en cuestión de meses, y el remedio no es la certificación — excluida del alcance de este estándar y sin regreso — sino la falsificabilidad: una declaración que nombra su deployment, su dueño, sus cláusulas, su periodo, su evidencia y sus limitaciones puede ser verificada o refutada por cualquiera, y el escrutinio público es más barato que un esquema de certificación y más difícil de capturar — habilita la verificación y la refutación; no sustituye una auditoría independiente. Una declaración vencida no es una declaración; la renovación puede compartir calendario con la revisión de existencia de HWF-63. La oración del proveedor es el candado anti-lavado, y la primera plataforma atada por ella es la del propio autor: AIEmpl.com puede declarar que habilita deployments conformes, y nunca puede llamarse a sí misma conforme. Un estándar que no gobierna cómo se lo invoca termina significando lo que el marketing necesite que signifique.

*Construida contra:* S9 · ISO 30414:2025 — Human resource management, HCRD

## Clasificación de riesgo

La clase se juzga sobre el riesgo inherente a través de siete factores — derechos afectados, escala de personas alcanzadas, reversibilidad, presencia de personas vulnerables, sensibilidad de los datos, exposición adversarial y concentración de poder — nunca sobre el costo del error a solas. Los controles bajan el riesgo residual; nunca bajan la clase.

| Clase | Significado | Régimen operativo |
| --- | --- | --- |
| Prohibido | Un uso que no puede volverse conforme mediante ningún control: exige engañar a las personas sobre el sistema (HWF-14), pasar sobre las restricciones de HWF-01, u operar fuera de toda cadena accountable. | No se realiza bajo este estándar, con ninguna configuración de recursos. |
| Crítico | Consecuencias severas o irreversibles para derechos, seguridad, dinero a escala o la organización misma. | Decisión humana final obligatoria en cada acción, separación de funciones, autonomía limitada a los peldaños 1–3 de la escalera de autonomía, auditoría reforzada. |
| Alto | Consecuencias serias pero en general recuperables, o moderadas amplificadas por escala, sensibilidad de datos o exposición adversarial. | Evaluación de impacto previa al deployment, validación independiente, supervisión reforzada, aprobación humana en clases de acción definidas. |
| Moderado | Consecuencias contenidas, reversibles con retrabajo y algo de fricción. | Autonomía acotada dentro de la matriz de autoridad, monitoreo continuo, revisión por muestreo. |
| Bajo | Consecuencias internas y fácilmente absorbibles. | Operación por excepción con controles base: identidad, audit trail, escalamiento. |

El HWFA deriva una clase provisional de costo del error y reversibilidad al asignar; la clase declarada de HWF-51 pesa los siete factores y prevalece. Los niveles están diseñados para interoperar con regímenes basados en riesgo como el EU AI Act sin afirmar equivalencia jurídica: mapear una clase a una categoría legal es un ejercicio de abogados, no una propiedad de este documento.

## Modelo de madurez

| Nivel | Nombre | Definición |
| --- | --- | --- |
| 0 | Herramienta | Genera contenido o responde. No actúa. |
| 1 | Asistente | Usa contexto para ayudar a un humano. |
| 2 | Agente | Ejecuta tareas acotadas con herramientas. |
| 3 | Agente de rol | Posee los workflows recurrentes de un rol definido. |
| 4 | Empleado IA | Las nueve propiedades de la definición, exhibidas en operación. |
| 5 | AI Team | Múltiples Empleados IA coordinados con contexto compartido. |
| 6 | Empresa Híbrida | Humanos y Empleados IA bajo un modelo integrado de organización, permisos y gobierno. |

**Umbral de la categoría: 4 — Empleado IA.**

La escalera mapea la evolución de capacidad y escala; no decide la membresía. El nivel 4 nombra el punto donde un deployment puede exhibir las nueve propiedades de la definición — si de verdad las exhibe lo decide el test, nunca el nivel. Los niveles 0 a 3 son destinos legítimos, no fracasos — un asistente bien ubicado puede producir más valor que un supuesto Empleado IA al que nadie supervisa.

### Autodiagnóstico

1. ¿Actúa, o solo produce output?
2. ¿Sostiene un rol recurrente, o solo tareas discretas?
3. ¿Siguiendo su cadena de supervisión hacia arriba, se llega a un humano con nombre?
4. ¿Puede reconstruir qué hizo el martes pasado y bajo qué autoridad?
5. ¿Puede suspenderse hoy, por alguien que sabe que esa decisión es suya?

## WRM — el marco

> WRM — Administración de Recursos de Trabajo — es la disciplina que diseña, asigna, gobierna y optimiza el trabajo independientemente de si el recurso que lo ejecuta es humano o artificial.

La idea fundacional es separar el puesto del ocupante. Primero existe una necesidad organizacional; de ella nace un puesto o responsabilidad, con propósito, ownership, resultados, KPIs, autoridad, límites, relaciones, herramientas y escalamiento. Después se decide cuál es el recurso correcto para ocuparlo. La declaración gobierna el orden del nacimiento, no el resto de la vida: los ocupantes — los humanos sobre todo — remodelan sus puestos, y un marco que negara el job crafting sería taylorismo con mejor vocabulario. Lo que el marco exige es que toda remodelación se declare y se versione, porque en una organización híbrida el puesto declarado es la interfaz: un colega humano puede leer un rol no declarado desde el pasillo; uno artificial solo puede leer el grafo.

### Dónde se ubica WRM

| Capa | Administra | Resultado |
| --- | --- | --- |
| WRM — Administración de Recursos de Trabajo | El trabajo, sus puestos, resultados, autoridad y controles | Arquitectura óptima del workforce |
| Human Resource Management | Personas que ejecutan trabajo | Desempeño + derechos + desarrollo humano |
| Artificial Resource Management | Sistemas de IA que ejecutan trabajo | Desempeño + seguridad + control técnico |
| Hybrid Workforce Management | Interacción y asignación entre ambos | Coordinación, transición y optimización |

### Tres clases de principio

| Clase | Cantidad | Significado |
| --- | --- | --- |
| U — Universales | 87 | Principios de administración del trabajo que deben respetarse sin importar quién ejecuta. |
| A — Adaptados | 20 | Principios humanos que conservan una función equivalente pero cambian de mecanismo. |
| H — Exclusivamente humanos | 13 | Derechos, necesidades y experiencias derivadas de la condición humana. |

**Analogías como «la IA necesita vacaciones» o «la IA siente engagement» importan mecanismos sin referente operativo, y forzarlas degrada el framework. La equivalencia debe ser operacional, nunca antropomórfica.**

### Los diez dominios

| # | Dominio | Alcance |
| --- | --- | --- |
| 1 | Diseño organizacional y de puestos | Propósito, responsabilidades, autoridad, ownership, unidad de mando e interdependencias. |
| 2 | Selección y asignación | Definir el puesto primero, evaluar fit, competencias, costo, riesgo y prueba previa. |
| 3 | Onboarding y habilitación | Conocimiento de empresa, SOPs, políticas, organigrama, herramientas y accesos. |
| 4 | Dirección, colaboración y comunicación | Delegación, escalamiento, handoffs, canales, contexto y reglas de interacción. |
| 5 | Objetivos y desempeño | KPIs, estándares de calidad, feedback, revisión, underperformance y mejora. |
| 6 | Aprendizaje y desarrollo | Brechas, entrenamiento, actualización, memoria, conocimiento y evolución de capacidades. |
| 7 | Experiencia humana y recompensas | Motivación, compensación, salud, descanso, derechos y relaciones laborales — cuando el recurso es humano. |
| 8 | Gobierno, seguridad y riesgo | Least privilege, segregación, auditabilidad, privacidad, incidentes y cumplimiento. |
| 9 | Movilidad, continuidad y salida | Promoción/scope, sucesión/fallback, transferencia, offboarding y conservación de conocimiento. |
| 10 | Workforce planning y analytics | Capacidad, make-vs-buy, mix humano/IA, costos, productividad, calidad y mejora continua. |

### Ciclo de vida del recurso de trabajo

| # | Etapa | Objetivo |
| --- | --- | --- |
| 1 | Diseñar | Definir resultado, responsabilidades, KPIs, autoridad, límites y riesgo. |
| 2 | Asignar | Decidir Humano / Humano asistido / Automatización determinista / Artificial. |
| 3 | Seleccionar | Persona, modelo, agente, vendor o arquitectura con fit demostrable. |
| 4 | Incorporar | Onboarding de conocimiento, SOPs, cultura/políticas, relaciones y escalamiento. |
| 5 | Habilitar | Herramientas, accesos, credenciales, presupuesto y autoridad. |
| 6 | Probar | Probation o shadow mode, simulaciones, evaluaciones y aprobación intensiva. |
| 7 | Operar | Trabajo recurrente con observabilidad y management by exception. |
| 8 | Medir | KPIs, calidad, costo, incidentes, intervenciones y outcomes. |
| 9 | Desarrollar | Coaching o actualización de instrucciones, conocimiento, modelos y herramientas. La señal puede originarse en el manager o en el recurso reportando divergencia a partir de sus propios datos. |
| 10 | Reasignar | Cambiar scope, mover entre tipos de ocupante, revisar qué funciones se ejecutan con asistencia. |
| 11 | Suspender | Detener trabajo o accesos ante riesgo, incidente o desempeño inaceptable. |
| 12 | Retirar | Offboarding, revocación, transferencia de conocimiento y retención/borrado. |

### Diez reglas no negociables

1. Todo puesto debe existir antes que su ocupante, con propósito, responsabilidades, resultados y KPIs — y ningún puesto debe sobrevivir a su propósito.
2. Todo recurso de trabajo debe tener exactamente un accountable owner, aunque colabore con múltiples personas o áreas y aunque su supervisión esté delegada. Un owner es primario, no exclusivo: las obligaciones de datos, seguridad, compliance y proveedor sobreviven intactas.
3. Responsabilidad y autoridad deben estar alineadas: no se exige un resultado sin entregar las facultades necesarias.
4. Toda autoridad debe ser explícita, limitada y revocable.
5. Todo recurso debe conocer sus límites, sus handoffs y cuándo escalar.
6. Los accesos se otorgan bajo least privilege y se separan de la identidad del modelo o del prompt. El contexto se aprovisiona sobre la misma base: lo que se concede y lo que se retiene son ambas decisiones de diseño registradas.
7. Toda acción material ejecutada por un Empleado IA debe ser trazable y auditable.
8. El desempeño se mide por outcomes, calidad, riesgo y costo; no por actividad, horas, tokens o cantidad de mensajes.
9. Una transición entre tipos de ocupante debe ser reversible hasta demostrar performance estable.
10. La responsabilidad final sobre un Empleado IA permanece en una persona identificada o cuerpo humano de gobierno, sin importar cuántos supervisores artificiales haya en el medio.

## La matriz de 120 principios

La matriz es una síntesis propia de prácticas de diseño organizacional, RR. HH., performance management, gobierno, workforce planning y riesgo. No es la transcripción de un único estándar existente, y la clasificación es una propuesta de trabajo de este framework — doctrina administrativa, no una afirmación jurídica sobre el empleo de software.

### 1. Diseño del trabajo y organización

| # | Principio | Recurso humano | Recurso artificial | Clase |
| --- | --- | --- | --- | --- |
| 1 | Todo puesto debe tener un propósito | El ocupante debe comprender por qué existe el puesto y qué valor crea. | El Empleado IA debe tener una misión operacional explícita y estable. | U |
| 2 | Descripción formal del puesto | Job description documentada. | AI Job Description / Role Contract versionado. | U |
| 3 | Responsabilidades definidas | Resultados y deberes asignados con claridad. | Procesos, decisiones y resultados bajo ownership explícito. | U |
| 4 | Límites del puesto | Debe quedar claro qué no le corresponde. | Acciones, dominios, datos y decisiones prohibidas. | U |
| 5 | Autoridad definida | Se especifica qué puede decidir sin aprobación. | Se especifican acciones autónomas, umbrales y approvals. | U |
| 6 | Responsabilidad y autoridad deben estar alineadas | No se exige un resultado sin facultades o recursos suficientes. | No se exige un KPI sin tools, permisos, datos y budget adecuados. | U |
| 7 | Unidad de mando / accountability claro | Debe existir un manager responsable del desempeño. | Exactamente un accountable owner — primario, no exclusivo — aunque reciba trabajo de varias áreas y la supervisión esté delegada. | U |
| 8 | Cadena de mando y escalamiento conocidos | Sabe a quién escalar una excepción o conflicto. | Escalation tree explícito por tipo, riesgo y urgencia. | U |
| 9 | Span of control razonable | Un manager no debe tener más reportes de los que puede dirigir efectivamente. | La escala puede ser mayor, pero requiere tooling, dashboards y límites de supervisión. | A |
| 10 | División del trabajo y especialización | Roles organizados por competencias y resultados. | Empleados IA o subagentes especializados por función. | U |
| 11 | Evitar duplicidad de ownership | No deben existir dos dueños ambiguos del mismo resultado. | Evitar que varios Empleados IA actúen sobre el mismo objeto sin coordinación o lock. | U |
| 12 | Interdependencias explícitas | Inputs, outputs y dependencias entre puestos conocidas. | Handoffs, APIs, humanos, otros Empleados IA y sistemas identificados. | U |

### 2. Selección e incorporación

| # | Principio | Recurso humano | Recurso artificial | Clase |
| --- | --- | --- | --- | --- |
| 13 | Definir el puesto antes de seleccionar al ocupante | Primero se diseña el rol; luego se busca la persona. | Primero se diseña el rol; luego se elige modelo, agente y configuración. | U |
| 14 | Seleccionar según competencias requeridas | Skills, experiencia, conocimientos y comportamientos. | Modelo, reasoning, herramientas, memoria, contexto e integraciones. | U |
| 15 | Validar competencias antes de contratar | Entrevistas, pruebas, referencias y assessment. | Benchmarks, evals, simulaciones, sandbox y red-team del rol. | U |
| 16 | No pagar por capacidad que el puesto no necesita | Evitar sobrecalificación costosa o mal aprovechada. | No usar el modelo más caro o capaz si uno menor cumple el SLA. | U |
| 17 | Fit puesto-recurso | Person-job fit y person-organization fit. | Model/agent-role fit y architecture-role fit. | U |
| 18 | Periodo de prueba | Probation con supervisión y criterios de éxito. | Shadow mode, sandbox o producción con approvals reforzados. | U |
| 19 | Verificación previa | Antecedentes, referencias y requisitos de confianza aplicables. | Security review, evaluación del vendor/modelo, provenance y supply-chain review. | A |
| 20 | Inducción a la organización | Historia, propósito, estrategia y estructura. | Contexto empresarial, estructura, objetivos y políticas cargados en la capa de conocimiento. | U |
| 21 | Conocer productos y servicios | Formación en oferta, clientes y propuesta de valor. | Knowledge base/RAG/context sobre productos, pricing, clientes y restricciones. | U |
| 22 | Conocer políticas | Manual, políticas internas y obligaciones. | Policy layer, system policies y reglas de cumplimiento. | U |
| 23 | Conocer procedimientos | SOPs, checklists y formas de trabajo. | SOPs ejecutables, instrucciones y workflows autorizados. | U |
| 24 | Conocer compañeros y estructura | Organigrama, stakeholders y responsabilidades. | Organizational graph con humanos, Empleados IA, roles, canales y ownership. | U |
| 25 | Conocer al supervisor | Manager asignado y expectativas de la relación. | Accountable manager registrado como parte del rol. | U |
| 26 | Conocer canales de comunicación | Email, Slack/Teams, reuniones, tickets y protocolos. | Canales autorizados, routing, recipients y reglas de comunicación. | U |
| 27 | Recibir herramientas de trabajo | Equipo, software, cuentas y acceso operativo. | Tools, APIs, credentials, browser, DBs, ERP/CRM y otros conectores. | U |
| 28 | Recibir únicamente accesos necesarios | RBAC y least privilege. | RBAC, least privilege, secrets aislados y scopes mínimos. | U |

### 3. Objetivos, dirección y desempeño

| # | Principio | Recurso humano | Recurso artificial | Clase |
| --- | --- | --- | --- | --- |
| 29 | Objetivos claros | Expectativas concretas sobre qué debe lograr. | Objectives explícitos, verificables y vinculados al Role Contract. | U |
| 30 | KPIs definidos | Métricas de desempeño del puesto. | KPIs, SLAs, calidad, costo y riesgo del Empleado IA. | U |
| 31 | Alinear KPIs con objetivos del negocio | Evitar métricas de vanidad o incentivos perversos. | Medir outcomes, no tool calls, tokens o actividad sin valor. | U |
| 32 | Metas alcanzables | Metas realistas según recursos y capacidad. | Metas realistas según modelo, contexto, herramientas y authority. | U |
| 33 | Feedback frecuente | Conversaciones de desempeño y corrección de rumbo. | El feedback del manager alimenta configuración, ejemplos, políticas, evals o prompts. | A |
| 34 | Evaluación periódica | Performance review formal o continua. | AI Performance Review con métricas, incidentes y quality samples. | U |
| 35 | Evaluar resultados, no mera actividad | Outcome y calidad por encima de horas visibles. | Outcome y reliability por encima de tokens, mensajes o pasos ejecutados. | U |
| 36 | Comparar resultado contra estándar | Quality bar, SLA o estándar profesional. | Test sets, golden datasets, thresholds y policy checks. | U |
| 37 | Responsabilidad por el desempeño | Empleado y manager participan del resultado. | El AI ejecuta; el accountable human conserva responsabilidad de negocio y gobierno. | A |
| 38 | Corregir bajo desempeño | Coaching, training, PIP o rediseño del puesto. | Modificar instrucciones, conocimiento, modelo, tools, workflow o scope. | A |
| 39 | Reconocer alto desempeño | Reconocimiento, promoción, compensación o mayor autonomía. | Mayor scope, autonomía, límites de autoridad o asignación a procesos más críticos. | A |
| 40 | Supervisión proporcional a competencia y riesgo | Junior requiere mayor supervisión; experto puede recibir más autonomía. | La autonomía aumenta solo con evidencia de reliability y según risk class. | U |
| 41 | Delegación explícita | El manager define qué delega y qué retiene. | Cada decisión o acción delegada debe constar en policy o authority matrix. | U |
| 42 | Management by exception | El manager interviene especialmente en desviaciones y excepciones. | La IA resuelve rutina dentro de límites y escala excepciones. | U |
| 43 | Escalamiento definido | Criterios para solicitar ayuda o aprobación. | Confidence/risk thresholds, timers, exception classes y human escalation. | U |
| 44 | Separación de funciones | Reduce fraude, error y concentración indebida de poder. | El AI que inicia un pago no debería aprobarlo; roles de maker/checker separados. | U |
| 45 | Principio de cuatro ojos | Decisiones sensibles requieren revisión adicional. | AI+humano, AI+AI+humano u otra aprobación proporcional al riesgo. | A |
| 46 | No otorgar más autoridad que la necesaria | Delegación mínima compatible con el trabajo. | Least authority y transactional limits. | U |
| 47 | La autoridad debe ser revocable | Suspensión o retiro de facultades cuando cambia el riesgo. | Kill switch, revoke credentials, disable tools o downgrade de autonomy. | U |

### 4. Desarrollo, conocimiento y comunicación

| # | Principio | Recurso humano | Recurso artificial | Clase |
| --- | --- | --- | --- | --- |
| 48 | Capacitación continua | Formación para mantener y ampliar capacidades. | Actualización de knowledge, tools, model, examples, policies y evals. | U |
| 49 | Identificar brechas de competencia | Skills gap analysis. | Capability gap a partir de eval failures, incidents y unsupported tasks. | U |
| 50 | Plan de desarrollo | Career path e Individual Development Plan. | Capability roadmap y criterios para ampliar scope o autonomy. | A |
| 51 | Coaching | El manager ayuda a mejorar criterio y ejecución. | El feedback humano transforma configuración, context, ejemplos y policy. | A |
| 52 | Aprender de errores | Lecciones aprendidas y acciones correctivas. | Postmortems, evals regresivos, memory controlada y guardrails nuevos. | U |
| 53 | Gestión del conocimiento | Capturar y compartir conocimiento crítico. | Shared knowledge layer, provenance, versioning y retrieval. | U |
| 54 | Actualizar ante cambios de políticas | Reentrenar cuando cambian reglas, productos o contexto. | Actualizar policy/context de forma inmediata y verificar comprensión con evals. | U |
| 55 | Comunicación clara de expectativas | Reducir ambigüedad en objetivos y estándares. | Role Contract, prompts, policies y definitions of done inequívocos. | U |
| 56 | Canales oficiales definidos | La organización determina dónde ocurre cada tipo de comunicación. | Channels y tools autorizados por tipo de interacción. | U |
| 57 | Contexto suficiente para decidir | La persona necesita información relevante y oportuna. | Context engineering, retrieval y memory suficientes; lo retenido es una decisión de diseño registrada, nunca un hueco silencioso. | U |
| 58 | Right information, right actor | Principio need-to-know. | Need-to-know enforced por RBAC, retrieval filters y data scopes. | U |
| 59 | Documentar decisiones importantes | Registro para continuidad, control y auditoría. | Logs estructurados, tool traces y decision records. | U |
| 60 | Handoffs claros | Transferencia explícita entre personas o equipos. | Agent-to-agent y AI-to-human handoffs con estado, contexto y ownership. | U |

### 5. Motivación, experiencia y compensación

| # | Principio | Recurso humano | Recurso artificial | Clase |
| --- | --- | --- | --- | --- |
| 61 | Sentido de propósito personal | Puede afectar motivación, compromiso y permanencia. | No existe como experiencia subjetiva del software. | H |
| 62 | Motivación intrínseca | Interés, maestría, autonomía y significado pueden impulsar desempeño. | No aplicable como estado psicológico. | H |
| 63 | Motivación extrínseca | Pago, reconocimiento, incentivos y consecuencias. | Puede existir una función de reward/optimization, pero no equivale a motivación humana. | A |
| 64 | Engagement | Compromiso psicológico con el trabajo y la organización. | No existe como experiencia subjetiva demostrable. | H |
| 65 | Satisfacción laboral | Importa para salud, permanencia y desempeño humano. | No aplicable al recurso artificial. | H |
| 66 | Sentido de pertenencia | Relación social y psicológica con el grupo. | No aplicable ontológicamente; solo puede simular conducta social. | H |
| 67 | Salario | Contraprestación económica por trabajo. | No hay salario; existen costos de modelo, SaaS, infraestructura, licencias y soporte. | A |
| 68 | Compensación justa | Equidad interna, externa y legal. | La optimización económica aplica, pero no como derecho del software. | A |
| 69 | Bonos por desempeño | Incentivo económico ligado a resultados. | No requiere incentivo psicológico; pueden usarse reward functions técnicas. | A |
| 70 | Beneficios | Salud, pensión, seguros, vacaciones y otras prestaciones. | No aplica al software. | H |
| 71 | Costo total del empleado | Salario + cargas + beneficios + equipo + administración. | Total Cost of AI Employment: modelos + infraestructura + integraciones + supervisión + errores + governance. | U |
| 72 | Salud ocupacional | Protección de salud física y mental. | No aplica como bienestar del AI; sí existen requisitos de seguridad operacional del sistema. | H |
| 73 | Descanso | Necesidad biológica y protección laboral. | No aplica biológicamente; se sustituye por maintenance windows, quotas y capacity management. | A |
| 74 | Jornada laboral | Protección humana sobre tiempo de trabajo. | Puede operar 24/7 sujeto a capacity, budget y reglas operativas. | H |
| 75 | Burnout | Riesgo humano por estrés sostenido. | No se trata como estado subjetivo; las realidades operativas son degradación, context pollution, saturation y error accumulation. | A |
| 76 | Seguridad psicológica | Permite hablar, discrepar y reconocer errores sin miedo indebido. | No aplica como experiencia subjetiva del AI, aunque sí importa para humanos que trabajan con él. | H |

### 6. Ética, conducta y relaciones laborales

| # | Principio | Recurso humano | Recurso artificial | Clase |
| --- | --- | --- | --- | --- |
| 77 | Código de conducta | Normas de comportamiento esperado. | Behavioral policies, output constraints y conduct rules. | U |
| 78 | Confidencialidad | Deber de reserva y cuidado de información. | Data access, disclosure policies, DLP y constraints. | U |
| 79 | Conflictos de interés | Identificar y gestionar intereses incompatibles. | Gestionar conflicts entre vendor, data source, goals, tools o roles. | A |
| 80 | No discriminación | Obligación ética y legal en decisiones sobre personas. | Fairness testing, policy constraints y human review de decisiones sensibles. | U |
| 81 | Honestidad e integridad | No engañar, falsear ni ocultar deliberadamente. | Políticas contra fabricación, impersonation, afecto simulado y claims no sustentados. | U |
| 82 | Protección de información | Custodia y uso apropiado de datos. | Data minimization, encryption, access control y retention. | U |
| 83 | Cumplimiento normativo | Respeto de leyes, políticas y estándares aplicables. | Compliance-by-design + human accountability. | U |
| 84 | Libertad sindical | Derecho humano de asociación laboral. | No aplica al software. | H |
| 85 | Negociación colectiva | Derecho de trabajadores humanos y organizaciones sindicales. | No aplica al software. | H |
| 86 | Procedimiento de quejas | Canal para que una persona reclame decisiones o condiciones. | No aplica subjetivamente al AI; sí deben existir canales humanos para reclamar acciones del AI. | H |
| 87 | Protección contra acoso | Derecho humano a un entorno libre de acoso. | No aplica al AI como víctima; sí sus outputs deben estar gobernados para no acosar a humanos. | H |
| 88 | Debido proceso disciplinario | Protección humana ante medidas disciplinarias. | No aplica como derecho del software; operacionalmente se reemplaza por incident review y change control. | A |

### 7. Gobierno, seguridad y riesgo

| # | Principio | Recurso humano | Recurso artificial | Clase |
| --- | --- | --- | --- | --- |
| 89 | Segregación de accesos | Limitar y separar privilegios según rol. | Fundamental: identity, RBAC, scopes y secrets separados. | U |
| 90 | Auditoría | Revisión independiente de procesos y decisiones. | Logs, traces, event history, evals y reproducibilidad. | U |
| 91 | Trazabilidad | Saber quién hizo qué, cuándo y bajo qué autoridad. | Actor ID + action + timestamp + context + tool + approval, más la política y versiones vigentes. | U |
| 92 | Accountability | Debe existir una persona responsable de decisiones y resultados. | Nunca debe quedar huérfano: un humano accountable responde por deployment, authority y outcomes. | U |
| 93 | Gestión de incidentes | Detectar, contener, investigar y aprender de fallas. | AI incident management con kill switch, rollback, postmortem y remediation. | U |
| 94 | Protección de datos | Principios de privacidad, acceso, minimización y retención. | Data governance, consent, retrieval filters, retention y deletion — cubriendo las inferencias derivadas y los propios logs de auditoría (HWF-42). | U |
| 95 | Gestión de riesgo | Identificar, evaluar, mitigar y monitorear exposición. | Risk classification por rol, tool, data y action; controles proporcionales. | U |

### 8. Movilidad, continuidad y salida

| # | Principio | Recurso humano | Recurso artificial | Clase |
| --- | --- | --- | --- | --- |
| 96 | Promoción | Mayor responsabilidad, alcance, estatus o compensación. | Mayor scope, autonomy, budget o authority tras evidencia. | A |
| 97 | Transferencia de puesto | Cambio de función o unidad. | Nuevo Role Contract, tools, context, permissions y manager. | U |
| 98 | Plan de sucesión | Preparar reemplazo para talento crítico. | Fallback agent/model/version y runbook de reemplazo. | U |
| 99 | Cross-training | Desarrollar flexibilidad para cubrir otras funciones. | Multi-capability, backup agents o ensembles, cuidando separation of duties. | U |
| 100 | Retención de talento/conocimiento crítico | Reducir pérdida de capacidades y know-how. | Reducir vendor/model lock-in; preservar prompts, policies, evals, memory y artifacts. | A |
| 101 | Criterios de terminación | Bajo desempeño, reestructuración, incumplimiento u otras causas. | Obsolescencia, costo, riesgo, incidents, bajo desempeño o cambio de arquitectura; la existencia se re-justifica con cadencia declarada (HWF-63). | U |
| 102 | Offboarding | Recuperar equipos, accesos, obligaciones y responsabilidades. | Revoke credentials, disable tools, remove schedules, queues y integrations. | U |
| 103 | Transferencia de conocimiento | Evitar pérdida de información al salir. | Exportar memory aprobada, context, artifacts, runbooks y outstanding tasks. | U |
| 104 | Protección de información después de la salida | Confidencialidad y cierre de accesos. | Retention/deletion policies, revocation y secret rotation. | U |
| 105 | Registro histórico | Employee file y evidencia de desempeño. | Audit/performance record versionado para governance y aprendizaje. | U |

### 9. Planificación de fuerza laboral

| # | Principio | Recurso humano | Recurso artificial | Clase |
| --- | --- | --- | --- | --- |
| 106 | Planificar capacidad futura | Headcount, skills y carga requeridos para la estrategia. | Human + AI capacity planning, concurrency y workload forecasting. | U |
| 107 | Make vs. buy | Contratar, tercerizar o desarrollar capacidad internamente. | Build agent vs. SaaS/vendor vs. managed service vs. open source. | U |
| 108 | Dimensionamiento | Número y mezcla de personas necesarias. | Instances, concurrency, model tiers y capacity requerida. | U |
| 109 | Diseñar el workforce mix | Full-time, part-time, contractors, outsourcing. | Asignación entre las cuatro salidas — Humano, Humano asistido, Automatización determinista o Artificial — según riesgo, costo y ventaja comparativa. | U |
| 110 | Productividad por recurso | Output/FTE y valor generado. | Outcome/Empleado IA, cost per outcome y human review load. | U |

### 10. Analítica y mejora continua

| # | Principio | Recurso humano | Recurso artificial | Clase |
| --- | --- | --- | --- | --- |
| 111 | Medir productividad | Cantidad/valor de output por recurso. | Outcomes por unidad de costo/tiempo del Empleado IA. | U |
| 112 | Medir calidad | Calidad contra estándar del puesto. | Accuracy, acceptance rate, QA score y policy compliance. | U |
| 113 | Medir costo | Costo total y marginal de operar el puesto. | Model + compute + tools + integrations + supervision + error cost. | U |
| 114 | Medir errores | Error rate, retrabajo e incidentes. | Hallucination/error rate, exception rate, incidents y recovery cost. | U |
| 115 | Medir disponibilidad | Asistencia/cobertura del recurso humano. | Uptime, queue readiness, dependency availability. | U |
| 116 | Medir utilización | Capacidad utilizada versus disponible. | Runtime/concurrency/tool utilization e idle capacity. | U |
| 117 | Medir tiempo a competencia | Time-to-productivity de una nueva contratación. | Time-to-autonomy: desde instanciación hasta desempeño confiable. | U |
| 118 | Medir rotación/reemplazo | Turnover y sus causas/costos. | Model/agent replacement rate, architecture churn y migration cost. | A |
| 119 | Benchmarking | Comparar desempeño entre personas, equipos o mercado. | Comparar models, configurations, prompts, agent versions y vendors. | U |
| 120 | Mejora continua | Optimizar procesos y workforce con evidencia. | Continuous evals, optimization, policy iteration y process redesign. | U |

## HWFA — Hybrid Workforce Fit Assessment

Instrumento estructurado en tres etapas — elegibilidad, luego riesgo, luego economía — para decidir si una responsabilidad debe ser Humano, Humano asistido, Automatización determinista o Artificial. Las restricciones van primero: las materias reservadas y los usos prohibidos compuertan la respuesta, el trabajo por reglas completamente enumerable sale hacia software convencional, el riesgo topa lo que sobrevive, y solo entonces el perfil de costos escoge entre lo restante. Devuelve un argumento, no un número: una asignación, una clase de riesgo, un peldaño inicial de autonomía, las respuestas que lo decidieron y las condiciones que lo cambiarían — un puntaje numérico permitiría lavar a través de la aritmética una decisión ya tomada.

### Las trece dimensiones

| Dimensión | Pregunta | Opciones, de menos a más apta para un recurso artificial |
| --- | --- | --- |
| Materias reservadas | ¿La responsabilidad decide materias que HWF-02 reserva a humanos? | Sí — sus decisiones centrales son reservadas: empleo, salud y seguridad, crédito o servicios esenciales, derechos legales, fuerza, personas vulnerables · Las materias reservadas aparecen con regularidad entre sus decisiones · Toca materias reservadas ocasionalmente, y pueden rutearse fuera · Nunca decide materias reservadas |
| Repetibilidad | ¿El trabajo sigue patrones? | Casi cada caso es distinto · Patrones flojos, variación frecuente · Patrones claros con alguna variación · Altamente repetitivo y bien definido |
| Predictibilidad | ¿Los escenarios son conocidos o modelables? | Aparecen situaciones nuevas constantemente · Conocidos a grandes rasgos, impredecibles en detalle · Mayormente conocidos y documentados · Inputs y outputs completamente enumerables |
| Disponibilidad de datos | ¿Existe contexto suficiente y autorizado? | El criterio vive en la cabeza de las personas · Parcialmente documentado y disperso · Documentado y accesible, requiere curaduría · Completo, vigente, autorizado y consultable |
| Necesidad de criterio | ¿Requiere juicio ambiguo o estratégico? | Juicio estratégico, prioridades en conflicto · Criterio contextual importante · Algo de criterio dentro de reglas claras · Seguimiento de reglas, poca interpretación |
| Significancia humana | ¿Qué significa la interacción para la persona del otro lado? | Hay dignidad, vulnerabilidad o poder sobre la persona en juego — o la relación es el producto · La confianza afecta materialmente el resultado · La cortesía importa, la relación no decide · Transaccional, sin componente relacional |
| Costo del error | ¿Cuál es el costo del error? | Severo: consecuencias legales, financieras o de seguridad · Alto: impacto relevante en cliente o dinero · Moderado: retrabajo y algo de fricción · Bajo: interno y fácilmente absorbible |
| Reversibilidad | ¿Una acción equivocada puede deshacerse? | Irreversible una vez ejecutada · Reversible a alto costo o con daño ya hecho · Reversible con esfuerzo dentro de una ventana · Reversible trivialmente |
| Volumen | ¿Cuántos casos fluyen por esta responsabilidad? | Un puñado de casos al mes · Constante pero modesto · Alto, ocupa capacidad real · Muy alto, hoy es un cuello de botella |
| Velocidad y 24/7 | ¿La disponibilidad continua aporta valor? | No, el horario laboral alcanza · Marginalmente útil · Claramente valiosa · Decisiva — la demora destruye el resultado |
| Auditabilidad | ¿Podemos verificar el resultado? | La calidad es cuestión de opinión · Verificable solo por muestreo · Verificable contra un estándar definido · Verificable automáticamente, criterios objetivos |
| Tasa de excepciones | ¿Qué porcentaje sale del camino normal? | La mayoría de casos son excepciones · Cerca de un tercio · Alrededor de uno de cada diez · Raras, bajo un pequeño porcentaje |
| Perfil de costos | ¿Dónde está hoy el costo de esta responsabilidad? | En criterio senior escaso aplicado caso por caso · En tiempo de relación que construye el resultado · En tiempo calificado consumido por casos repetitivos · En cobertura: colas, espera y demanda fuera de horario |

### La escalera de autonomía

| Peldaño | Nombre | Detalle |
| --- | --- | --- |
| 1 | Observar | Registra y compara sin intervenir. Shadow mode contra un baseline humano. |
| 2 | Recomendar | Propone la acción y muestra la evidencia utilizada. Un humano ejecuta. |
| 3 | Ejecutar con aprobación | Actúa solo tras aprobación humana explícita, caso por caso. |
| 4 | Actuar por excepción | Actúa dentro de reglas; el manager interviene solo en excepciones. |
| 5 | Autónomo dentro de límites | Opera autónomamente dentro de límites definidos, con trazabilidad y escalamiento. |

**Ninguna responsabilidad arranca por encima del peldaño 3, diga lo que diga la evaluación. La autonomía se gana con evidencia de desempeño estable, nunca se concede porque el modelo parezca capaz.**

## El rol: Gerente de Fuerza Laboral Híbrida

### Misión

> Diseñar, equilibrar y optimizar la fuerza laboral humana y artificial, asegurando que cada responsabilidad sea ejecutada por el recurso — humano o artificial — que genere el mejor resultado con el nivel adecuado de costo, riesgo, calidad y accountability.

En organizaciones grandes puede evolucionar a Director of Hybrid Workforce. Debe ubicarse dentro de RR. HH./People & Workforce, con relación matricial fuerte con el COO y el CIO/CTO. No toda empresa necesita crear el cargo mañana — pero cualquier organización que conceda role stewardship a recursos artificiales necesita que alguien ejerza estas funciones.

### Responsabilidades

1. Armonía operacional humano-IA: eliminar ownership contradictorio, definir handoffs y líneas de escalamiento.
2. Evaluar periódicamente qué trabajo debe ser Humano, Humano asistido, Automatización determinista o Artificial.
3. Dirigir transiciones entre tipos de ocupante, en ambas direcciones.
4. Diseñar puestos híbridos y reparto explícito de responsabilidades.
5. Administrar el impacto humano: claridad, comunicación, reasignación y desarrollo.
6. Garantizar que todo Empleado IA tenga Role Contract, manager, KPIs, permisos, límites, audit trail, performance review, y un kill switch ejercitado con cadencia declarada (HWF-23).
7. Coordinar con IT/Security para accesos, runtime, observabilidad e incidentes.
8. Mantener neutralidad respecto al tipo de recurso dentro de la frontera de HWF-01: no tiene como meta «usar más IA» ni «proteger puestos»; tiene como meta optimizar el trabajo dentro del espacio que dejan abierto los derechos, la dignidad, la seguridad y las protecciones laborales.
9. Reportar al liderazgo costo por outcome, calidad, riesgo, capacidad liberada y performance del workforce.
10. Mantener el inventario oficial de puestos, actores humanos/artificiales y su estado de madurez.

### El anti-KPI

**Nunca medir este rol por número de humanos reemplazados ni por porcentaje de puestos convertidos a IA. Esos KPIs crean un incentivo perverso: premian la conversión en vez del resultado, y garantizan que la persona encargada de proteger la calidad de la decisión cobre por prejuzgarla.**

### Scorecard

| KPI | Qué mide |  |
| --- | --- | --- |
| Workforce Performance Index | Resultado global del workforce vs. objetivos. |  |
| Role Allocation Accuracy | % de roles cuya asignación — Humano, Humano asistido, Automatización determinista o Artificial — se mantiene válida tras revisión. |  |
| Transition Success Rate | Transiciones que alcanzan criterios de éxito sobre el total. |  |
| Time to Stable Performance | Días hasta alcanzar KPIs y nivel de riesgo esperado. |  |
| Post-Transition Performance Delta | Cambio de performance después de la transición. ¿El trabajo funciona mejor que antes? | **al CEO** |
| Cost per Successful Outcome | Costo total dividido por resultados correctos y aceptados — supervisión y retrabajo incluidos. | **al CEO** |
| Quality Delta | Cambio de calidad pre vs. post transición. |  |
| AI Exception Rate | Casos escalados sobre casos procesados — una señal de salud, nunca un objetivo: lo que importa no es cuántas escalaciones, sino si fueron las correctas. |  |
| Human Intervention Rate | Ejecuciones que requieren corrección humana. Al alza significa que la autonomía del papel no es real; a la baja con un Missed Escalation Rate al alza significa que el sistema aprendió a dejar de preguntar. | **al CEO** |
| Missed Escalation Rate | Casos que debieron escalar y no lo hicieron, encontrados en auditoría o después del daño. La dirección peligrosa. | **al CEO** |
| Unnecessary Escalation Rate | Escalaciones que un humano resolvió trivialmente — ruido que erosiona la atención del revisor. La escalación apropiada es el residuo de estas dos. |  |
| Correction Severity | Cuando un humano corrigió, qué tan grave era lo atrapado. Ata la carga de revisión a lo que realmente previene. |  |
| Human Review Burden by Risk Class | Horas de revisión por clase de riesgo. La sobrecarga en Crítico es el problema de la firma de HWF-02 tomando forma. |  |
| Unresolved High-Risk Exceptions | Cola envejecida de excepciones Altas y Críticas sin resolución. |  |
| Harmful Outcome Severity | Daño ponderado por severidad que llegó a clientes o trabajadores. | **al CEO** |
| Workforce Clarity Score | Claridad de roles, ownership y escalamiento. |  |
| Human Capacity Reallocation Rate | Horas liberadas que pasan a trabajo de mayor valor sobre horas liberadas. |  |
| Hybrid Workforce Incident Rate | Incidentes atribuibles a diseño humano/IA. | **al CEO** |
| Role Conflict Rate | Conflictos de ownership por período. |  |
| AI Employee SLA Compliance | Cumplimiento de SLA del rol artificial. |  |
| Workforce ROI | (Valor incremental − costo workforce) / costo workforce. |  |

**Las métricas de escalación son señales de salud, no objetivos. Un sistema premiado por escalar menos aprende silencio — la falla exacta que HWF-34 existe para impedir — así que la escalación se juzga por calidad, nunca por volumen: el par que importa es perdidas versus innecesarias, la escalación apropiada es el residuo de las dos, y ninguna métrica de este scorecard puede cargar un incentivo hacia el silencio.**

Seis de estos llevan la bandera ejecutiva: si el trabajo funciona mejor que antes, cuánto cuesta un resultado correcto, cuánta autonomía es real, qué debió escalar y no escaló, qué daño pasó, y qué incidentes produjo el diseño. Y el dashboard no es solo este scorecard — también muestra lo que otras cláusulas ya generan: quejas y apelaciones de personas afectadas (HWF-04), riesgo residual contra la clase declarada (HWF-51), drift desde la última revalidación (HWF-52), y las consecuencias laborales que las evaluaciones de impacto registraron (HWF-03). Un dashboard que solo muestra performance y costo es el que quiere un CFO; este es el que necesita un board.

### Capacity Elevation Rate

La proporción de capacidad humana liberada por automatización que se trasladó a trabajo de mayor valor. La métrica existe para impedir que la palabra «productividad» esconda lo que realmente pasó. Las horas liberadas pueden convertirse en análisis, servicio, innovación, liderazgo, eliminación de desperdicio — o en una reducción real de headcount. Son decisiones distintas y deben contarse por separado. La tecnología puede liberar horas; no puede decidir para qué son.

## Transiciones

### Humano → Artificial

El objetivo no es «sustituir a una persona». Es transferir responsabilidad de forma controlada después de demostrar que el nuevo diseño produce resultados iguales o mejores dentro del riesgo permitido.

**Antes del paso uno: la evaluación de impacto humano de HWF-03, registrada, con los trabajadores afectados y sus representantes informados y consultados. El playbook transfiere el trabajo; la evaluación gobierna lo que la transferencia le hace a la gente.**

| # | Paso | Control |
| --- | --- | --- |
| 1 | Baseline | Documentar el desempeño actual: calidad, costo, tiempo, errores, excepciones y conocimiento tácito. |
| 2 | Descomposición | Separar el puesto en responsabilidades y tareas; identificar qué debe seguir siendo humano. |
| 3 | Risk mapping | Clasificar decisiones, datos, autoridad y costo del error. |
| 4 | Role Contract AI | Crear job description, KPIs, límites, herramientas, manager y escalamiento. |
| 5 | Knowledge transfer | SOPs, ejemplos, criterios, políticas, excepciones e historial. |
| 6 | Shadow mode | El Empleado IA ejecuta sin afectar producción; se compara contra el humano. |
| 7 | Producción controlada | Autoridad limitada y aprobaciones frecuentes. |
| 8 | Performance gate | No se transfiere ownership hasta alcanzar umbrales de calidad, costo y riesgo. |
| 9 | Transferencia gradual | Aumentar scope y autonomía; mantener reversibilidad. |
| 10 | Reasignación humana | Mover capacidad humana liberada hacia trabajo de mayor valor, contra el plan de capacitación y reasignación registrado en la evaluación de impacto (HWF-03). |
| 11 | Handoff formal | Actualizar organigrama, RACI/ownership, accesos y comunicación. |
| 12 | Revisión post-transición | Revisar a 30/60/90 días y revertir si el desempeño se deteriora. |

**No se sustituye primero y se descubre después si funcionaba. La transición se gana con evidencia.**

### Artificial → Humano

El framework debe ser reversible. Si el recurso artificial produce demasiado riesgo, baja calidad, exceso de intervención humana, costo creciente o deterioro relacional, el trabajo debe regresar parcial o totalmente a manos humanas. Una organización híbrida madura no mide el éxito por la dirección de la transición. Lo mide por la calidad de su arquitectura.

1. Activar criterio de rollback por KPI o incidente.
2. Congelar o reducir la autoridad del Empleado IA.
3. Transferir contexto, memoria útil y backlog al humano.
4. Reasignar ownership y canales de escalamiento.
5. Revocar accesos artificiales que ya no correspondan.
6. Ejecutar root-cause analysis: modelo, proceso, conocimiento, herramientas o mala asignación del rol.
7. Decidir si el futuro del puesto es Humano o Humano asistido, no asumir que debe volver a ser humano sin asistencia.

Defina las condiciones de regreso antes del piloto, no después de conocer los resultados. ¿Qué tasa de error es inaceptable? ¿Cuánta intervención humana destruye la economía? ¿Qué incidente obliga a suspender? Escritas de antemano, estas reglas reducen el sesgo de defender una implementación por orgullo.

## Glosario

Un término, dos idiomas, una definición numerada. Cuando el término inglés se usa sin traducir en la práctica en español, ambas entradas llevan la misma palabra — es una decisión deliberada para impedir que el vocabulario se fragmente entre las dos ediciones de este estándar.

**Los acrónimos no se traducen. WRM, HWFA y los identificadores de cláusula HWF- se mantienen idénticos en toda edición de este estándar, presente y futura; solo se localizan las palabras que expanden. Quien cite WRM o HWF-44 en cualquier idioma está señalando lo mismo.**

**G-01 · Empleado IA** — Trabajador de software persistente y ligado a un rol, que ejecuta de forma autónoma responsabilidades recurrentes dentro de límites explícitos, con identidad trazable, desempeño medible, rutas de escalamiento y accountability humano.

**G-02 · WRM — Administración de Recursos de Trabajo** — La disciplina que diseña, asigna, gobierna y optimiza el trabajo independientemente de si el recurso que lo ejecuta es humano o artificial.

**G-03 · AI Role Contract** — El contrato operacional de un puesto artificial: misión, responsabilidades, resultados, KPIs, autoridad, exclusiones, herramientas, accesos, nivel de servicio, escalamiento, criterios de suspensión, calendario de gobernanza y accountable owner. Versionado. Equivale a una descripción de puesto más un acuerdo explícito de operación — un prompt da instrucciones, un contrato de rol da responsabilidad.

**G-04 · Accountable owner** — El único humano identificado, o cuerpo humano de gobierno, que responde por la configuración, autoridad, desempeño y excepciones de un Empleado IA. Exactamente uno, aunque el recurso reciba trabajo de varias áreas y aunque su supervisión cotidiana esté delegada. La accountability nunca es delegable a un recurso artificial, porque responder por un resultado exige capacidad de soportar una consecuencia. Primario, no exclusivo: las obligaciones de sistema, datos, seguridad, compliance, proveedor y directores sobreviven intactas (HWF-21). Un cuerpo de gobierno califica como owner solo con presidente identificado, reglas de decisión declaradas y capacidad de emergencia.

**G-05 · Shadow mode** — Etapa en la que el recurso artificial ejecuta el trabajo pero sus acciones no afectan la operación. Los resultados se comparan contra un baseline humano. Equivalente operativo del periodo de prueba.

**G-06 · Context Provisioning** — El equivalente al onboarding para un recurso artificial. Se divide en debe saber, puede consultar y no debe acceder. La tercera categoría tiene dos fundamentos legítimos: proteger la información del recurso, y proteger la decisión de la información (HWF-35); en ambos casos la restricción queda registrada, nunca silenciosa.

**G-07 · Matriz de autoridad** — El registro de qué puede leer, escribir, decidir, gastar, comunicar o ejecutar un recurso, y cuáles de esas acciones requieren aprobación. La autonomía sin matriz de autoridad es una palabra vacía.

**G-08 · Árbol de escalamiento** — El mapeo explícito de tipo de excepción, riesgo y urgencia hacia un destino: una persona, un equipo o una regla de retorno. Toda excepción necesita un destino.

**G-09 · Memoria gobernada** — Memoria con procedencia, alcance, retención y reglas de borrado, además de un dueño con nombre y un mecanismo de actualización. Una política sin fecha produce respuestas consistentes y equivocadas.

**G-10 · Human Intervention Rate** — La proporción de casos o decisiones que requieren corrección humana. Revela cuánta de la autonomía declarada es real y cuánta es automatización sostenida en silencio por personas.

**G-11 · Cost per Successful Outcome** — Costo total de producir un resultado correcto y aceptado — incluyendo plataforma, integración, supervisión, retrabajo, incidentes y operación humana residual. Comparar una suscripción contra un salario es el benchmark equivocado.

**G-12 · Post-Transition Performance Delta** — El cambio de desempeño después de cambiar el recurso o la configuración. No pregunta si el agente es rápido; pregunta si el puesto mejoró. Sin baseline, una organización puede celebrar una mejora que nunca ocurrió.

**G-13 · HWFA — Hybrid Workforce Fit Assessment** — Instrumento estructurado en tres etapas — elegibilidad, riesgo, economía — para decidir si una responsabilidad debe ser Humano, Humano asistido, Automatización determinista o Artificial. Devuelve un argumento, no un número: una asignación, una clase de riesgo, un peldaño inicial de autonomía y las condiciones que cambiarían la respuesta. Antes Fit Score; renombrado porque un instrumento que se niega a producir un número no debería llamarse así.

**G-14 · Gerente de Fuerza Laboral Híbrida** — El rol responsable de asegurar que cada responsabilidad sea ejecutada por la configuración que produce el mejor resultado. Neutral por diseño: nunca se mide por humanos reemplazados ni puestos convertidos.

**G-15 · Capacity Elevation Rate** — La proporción de capacidad humana liberada que se trasladó a trabajo de mayor valor. Evita que «productividad» esconda si las horas se convirtieron en análisis, servicio, innovación, desperdicio eliminado — o en una reducción de headcount que debe nombrarse.

**G-16 · Kill switch** — La capacidad técnica y de proceso de suspender un Empleado IA de inmediato. Un kill switch sin responsable es apenas una función; el contrato de rol debe decir quién puede usarlo y bajo qué condición.

**G-17 · Least privilege / least authority** — Least privilege limita a qué puede acceder un recurso; least authority limita qué puede decidir o comprometer. Son controles distintos y ambos son necesarios.

**G-18 · Role stewardship vs. task execution** — «Envía estos veinte seguimientos» es una tarea. «Administra el seguimiento comercial de esta cartera» es un rol: priorizar, respetar restricciones, conservar contexto, reconocer excepciones y escalar. El paso de una a otro es lo que justifica la categoría.

**G-19 · Plan de remediación** — El equivalente artificial de un plan de mejora: reducir scope, aumentar aprobaciones, corregir configuración o contexto, y validar nuevamente antes de restituir autoridad.

**G-20 · Arquitectura de fallback** — El plan de sucesión de un recurso artificial: modelo, agente o vendor alternativo, más un runbook de reemplazo. Reduce lock-in y hace sobrevivible el retiro.

**G-21 · Offboarding / deprovisioning** — Revocar credenciales, deshabilitar herramientas, detener schedules y colas, rotar secretos, transferir trabajo pendiente y contexto, preservar evidencia. Tan importante como el onboarding y casi siempre omitido.

**G-22 · Time-to-autonomy** — Días desde la instanciación hasta el desempeño confiable en el nivel de riesgo esperado. La contraparte artificial del time-to-productivity de una nueva contratación.

**G-23 · Total Cost of AI Employment** — Modelos más infraestructura más integraciones más supervisión más costo de errores más governance. El análogo artificial del costo total del empleado, y la única base honesta de comparación.

**G-24 · Management by exception** — El modo de operación en que el recurso resuelve la rutina dentro de sus límites y el manager interviene en desviaciones y excepciones. Peldaño 4 de la escalera de autonomía.

**G-25 · Humano asistido** — Puesto ocupado por una persona, algunas de cuyas funciones se ejecutan con asistencia artificial. El ocupante es humano: la accountability, las decisiones y la relación con la contraparte quedan en la persona, mientras el recurso artificial prepara, redacta, analiza o recomienda. No es un tercer tipo de empleado — es un empleado humano, asistido. Lo híbrido es la fuerza laboral, no la persona.

**G-26 · Supervisor** — Quien dirige el trabajo cotidiano de un Empleado IA: rutear tareas, revisar output, fijar prioridades y recibir excepciones. Un supervisor puede ser humano o artificial. Se distingue del accountable owner, que siempre es humano: un Empleado IA puede supervisar a otro y aun así responder ante una persona en algún punto por encima.

**G-27 · Cadena de supervisión** — El recorrido desde un Empleado IA hacia arriba, a través de cada supervisor, hasta el humano o cuerpo de gobierno accountable. Se permiten cadenas de cualquier profundidad, pero cada una debe terminar en un humano, ser recorrible y observable de punta a punta, y permitir que quien responde intervenga en cualquier punto sin pasar por la cadena misma. La profundidad la acota el span of control y no un número fijo: la escala puede crecer solo contra tooling que la haga gobernable.

**G-28 · Divergencia de rol** — La brecha entre lo que un Empleado IA realmente produce y la misión, autoridad o KPIs que declara su contrato de rol. El recurso la reporta a su accountable owner como hallazgo, nunca como solicitud: el recurso no tiene intereses que defender, y la decisión de revisar el contrato queda en el humano. La divergencia es la señal de que un contrato envejeció, no la prueba de que el recurso merece más.

**G-29 · Determinantes de la decisión** — El estado que produjo una acción concreta: la política vigente, el conocimiento recuperado y su procedencia, los resultados que devolvieron las herramientas, la autoridad en efecto, y las versiones de modelo y configuración corriendo en ese momento. Se distingue del resultado, que dice qué pasó, y de una traza de razonamiento, que dice qué reporta el sistema haber pensado. Los determinantes son lo que permite atribuir una falla a una causa en vez de solo registrarla.

**G-30 · Interioridad simulada** — Conducta cuyo resultado es que una persona crea que un recurso artificial atraviesa una vida interior, cuando nada garantiza la atribución: latencia inyectada e indicadores de tipeo que hacen de pensamiento, vacilación verbal, o declaraciones de sentimiento y cuidado. Se distingue de la comunicación clara y cortés, que es competencia. Las pruebas son los dos estándares verificables de HWF-14 — si una persona razonable, sabiendo lo divulgado, formaría una creencia falsa a partir de la señal, y si los objetivos registrados de optimización apuntaron a la dependencia emocional o la vulnerabilidad. Prohibida incluso cuando el sistema haya declarado que es software.

**G-31 · Registro de frontera de contexto** — El artefacto registrado detrás de toda restricción de contexto (HWF-35): qué se le retiene a un recurso artificial, bajo cuál de los dos fundamentos legítimos — proteger la información, o prevenir la degradación medible de la decisión por anclaje, contaminación o saturación — decidido por quién, y versionado como cualquier otra autoridad. Se distingue de una omisión por exactamente una propiedad: está escrito. Una restricción sin registro es un hueco, y la responsabilidad por lo que degrade recae en quien retuvo el contexto.

**G-32 · Zombi digital** — Un Empleado IA cuyo puesto perdió su justificación pero que sigue operando con credenciales, accesos a datos y autoridad vigente intactos. Es lo que se acumula cuando nada fuerza la pregunta de existencia: hasta los disparadores débiles que a veces podan puestos humanos — una línea de salario bajo revisión de presupuesto, una renuncia que fuerza la decisión de reemplazo — no existen para un recurso que cuesta poco y no renuncia jamás. Se previene con la cadencia de re-justificación de HWF-63; se desmonta con el retiro del lifecycle, con offboarding y revocación.

**G-33 · Neutralidad de recurso** — La disciplina de asignación que decide quién ocupa un puesto — humano o artificial — sin preferencia previa por ninguno, juzgando solo fit, resultado, costo, riesgo y control. Es una disciplina, no una postura moral, y está acotada: la neutralidad comienza solo después de satisfechas las restricciones de HWF-01 — derechos, dignidad, seguridad, agencia humana significativa, accesibilidad, protecciones laborales. Citado sin su frontera, el término está siendo mal usado.

**G-34 · Unidad de conformidad** — Aquello sobre lo que puede tratar una declaración de conformidad: un deployment — un rol, una versión de contrato de rol, un accountable owner, un periodo de evaluación con expiración. Productos, plataformas, modelos y organizaciones en abstracto no pueden conformar, diga lo que diga su marketing; un proveedor solo puede declarar que habilita deployments conformes (HWF-71).

**G-35 · Clase de riesgo** — Uno de cinco niveles — Prohibido, Crítico, Alto, Moderado, Bajo — asignado a un puesto de Empleado IA juzgando el riesgo inherente a través de siete factores, antes de los controles. Los controles bajan el riesgo residual, nunca la clase (HWF-51). Se declara en toda declaración de conformidad (HWF-71); de Crítico hacia arriba toda acción termina en una decisión humana final, y un uso Prohibido no tiene configuración conforme alguna.

**G-36 · Decisión reservada** — Un asunto de decisión que un recurso artificial nunca puede tomar solo, sin importar la clase de riesgo evaluada del puesto: efectos materiales sobre empleo, salud y seguridad, crédito y servicios esenciales, derechos legales, uso de la fuerza o personas vulnerables (HWF-02). El recurso puede analizar, redactar y recomendar; un humano decide — y solo cuenta como decidir mientras pueda reformular el caso y decidir distinto. Aprobar a un ritmo que impide entender es una firma, no una decisión.

**G-37 · Evaluación de impacto humano** — La evaluación registrada que HWF-03 exige antes de cualquier transformación material de un puesto: a quiénes afecta; cambios en trabajo, autonomía y vigilancia; deskilling; carga de excepciones; discriminación y accesibilidad; desplazamiento y reducción de personal; capacitación y reasignación; efectos sobre clientes y terceros. Completada, informada y consultada antes de que la transición comience — no después. No está obligada a ser favorable; está obligada a ser honesta. Distinta de la evaluación de impacto por clase de riesgo de HWF-51, que protege la operación: esta protege a las personas.

**G-38 · Persona afectada** — Cualquiera sobre quien la acción de un Empleado IA tiene efecto material — cliente, trabajador o tercero. Titular de los siete derechos de HWF-04: divulgación de la intervención artificial, la organización responsable, revisión humana con autoridad para cambiar el resultado, corrección de datos, impugnación, una explicación accionable de los determinantes, y reparación. La explicación le llega a través de criterio humano: el material confidencial puede retenerse con razón registrada, y el deber de explicar nunca se cancela.

**G-39 · Zona de absorción moral** — El humano colocado al final de un proceso automatizado que absorbe la culpa de fallas cuyos determinantes están aguas arriba, en la política, el diseño, el tooling o el deployment. Nombrada por Elish, quien mostró que la culpa en sistemas automatizados aterriza en el humano más cercano mientras el control estaba en otra parte. Prohibida por HWF-23: la culpa sigue a los determinantes (HWF-41), no a la proximidad, y el humano que supervisa responde solo por lo que controló.

**G-40 · Inferencia derivada** — Un dato que el deployment fabrica sobre una persona en vez de recolectarlo de ella: una probabilidad de apuros financieros, una condición de salud inferida, una intención predicha. Gobernado bajo HWF-42 como si se hubiera recolectado — finalidad, base, minimización, eliminación — y con frecuencia más sensible que todo lo que la persona sí entregó. Una inferencia que la persona nunca entregó sigue siendo su dato.

**G-41 · Falla correlacionada** — El modo de falla de la monocultura de modelo. Los equipos humanos tampoco fallan de forma independiente, pero la diversidad de experiencia y criterio tiende a distribuir algunos puntos ciegos; las instancias que comparten modelo, proveedor, contexto o configuración los concentran, y pueden fallar del mismo modo al mismo tiempo. El precedente es la falla de causa común, conocida desde hace décadas en ingeniería de confiabilidad y en planes de continuidad; lo nuevo es la velocidad, el alcance y la opacidad con que se propaga dentro de una fuerza laboral artificial. Se mitiga con diversidad de modelos y proveedores, recursos de fallback y planes de sucesión; nombrado como ítem de validación para equipos de IA por HWF-52.

**G-42 · Entidad (frente a interfaz)** — Lo que separa a un empleado — humano o artificial — de un canal. Una interfaz es una superficie a través de la cual se alcanza algo; una entidad es una parte con la que se trata. Un Empleado IA sostiene conversaciones con clientes, proveedores y colegas, y puede fijar la posición de la organización a la que pertenece. Nadie es media contraparte, y por eso un ocupante es humano o artificial y nunca ambos: repartir el trabajo entre dos ocupantes produce dos puestos, no un puesto de un tercer tipo.

## Gobierno

### Divulgación

Este estándar fue escrito por Master Joe Phillips, quien también construye AIEmpl.com, una plataforma comercial en esta categoría. Eso es un conflicto de interés real y se declara aquí en lugar de descubrirse después. También escribió el libro acompañante, cuyas ediciones digitales se regalan: explica este estándar y no lo extiende.

De ahí se derivan tres compromisos, y los tres son estructurales y no prometidos. Este estándar no certifica productos ni puntúa proveedores, y bajo HWF-71 la plataforma del autor no puede jamás reclamar conformidad — un deployment puede, una plataforma no. La licencia es irrevocable, así que el texto no puede retirarse detrás de un producto. Y el texto normativo se mueve sin el voto del autor: el Editor redacta y argumenta, y no vota. Esa independencia está diseñada en la estructura y entra en vigor por etapas — custodia editorial hasta el congelamiento del 1 de septiembre de 2026 a las 00:00 UTC, texto inmóvil desde esa fecha salvo por el proceso aquí descrito, y autoridad colegiada cuando un Board se constituya con quórum. Diseñada hoy; lograda cuando los asientos estén ocupados.

Un estándar escrito por un vendor y juzgado por nadie es una hoja de especificaciones con nombre formal. El mecanismo de abajo es lo que debería impedir que este se convierta en eso.

### Editor y Review Board

> El Editor escribe, propone y decide todo lo editorial. Desde el congelamiento, el texto normativo cambia solo por votación del Board — y el Editor tiene voz, mas no voto. Hasta el congelamiento, la Candidate es un borrador bajo custodia del Editor, y su historial de redacción es público, commit por commit, en el repositorio.

Esa única regla es la que le da valor a la divulgación anterior: el autor tiene el mayor interés comercial de la sala. Hasta el congelamiento conserva la custodia editorial, y lo dice; desde el congelamiento no puede mover el estándar — solo persuadir a quienes sí podrán, cuando el Board exista.

### Los nueve asientos

| # | Asiento | Protege | Titular |
| --- | --- | --- | --- |
| 1 | RR. HH. / People | Que la traducción RR. HH.→IA no sea caricatura, y que las capas Humana y Adaptada de la matriz se mantengan honestas. | *Abierto* |
| 2 | Ejecutivo de operaciones o finanzas que haya desplegado IA | Que el estándar sea algo que una empresa real pueda cumplir, no solo algo elegante de leer. | *Abierto* |
| 3 | Ingeniería de IA | Que las nueve propiedades y los controles sean técnicamente honestos e implementables. | *Abierto* |
| 4 | Seguridad y riesgo | Least privilege, auditabilidad, manejo de incidentes y kill switch: el dominio de gobierno. | *Abierto* |
| 5 | Legal y laboral | La frontera que dice que esto no es un empleado en sentido jurídico. Es la línea donde la categoría tiene más probabilidad de quemarse. | *Abierto* |
| 6 | Representación de trabajadores | El piso de HWF-02 y HWF-03: que las decisiones reservadas sigan humanas y que las evaluaciones de impacto consulten a los trabajadores antes de la transformación, no después. Experiencia de piso en comités o sindicatos, no un teórico. | *Abierto* |
| 7 | Personas afectadas y sociedad civil | Que los derechos de HWF-04 funcionen como mecanismos y no como palabras: explicación, corrección, impugnación y reparación. Alguien que opere recursos en el mundo real — ombudsman, protección al consumidor, práctica de apelaciones. | *Abierto* |
| 8 | Accesibilidad e inclusión | La restricción de accesibilidad de HWF-01 y el factor de personas vulnerables de HWF-51 y HWF-02. Un practicante de sistemas accesibles, no un auditor de documentos. | *Abierto* |
| 9 | Académico independiente | La base de evidencia: que las afirmaciones del estándar sobrevivan el contacto con la investigación, y que sus fuentes se mantengan honestas. Teoría organizacional, economía laboral o interacción humano-computadora, sin interés comercial en la categoría. | *Abierto* |

1. La mayoría del Board deben ser personas operando hoy en el campo — desplegando, construyendo o gobernando fuerzas laborales híbridas. El skin in the game es un requisito de este Board, no un descalificador: lo que descalifica es el interés oculto, nunca el interés.
2. El interés comercial en la categoría — competidores del autor incluidos — puede ocupar como máximo dos de los nueve asientos, cada uno con divulgación publicada y recusación en todo voto donde el interés sea directo — la direccionalidad la juzgan los asientos no conflictuados, nunca el propio miembro. El Board no es un lobby de vendors ni una lista negra de vendors.
3. Compensación transparente o ninguna: un honorario idéntico, publicado y de fuentes divulgadas. Los asientos sin pago seleccionan a quienes pueden donar su tiempo; el pago oculto selecciona a quienes alguien más les paga. Ambos son captura — la transparencia es el control.
4. Cada miembro publica su propia divulgación, exactamente como lo hace el Editor.
5. Términos de doce meses renovables, para que salir sea algo ordinario y no un escándalo.
6. Un voto es válido solo con dos tercios de los asientos ocupados participando, y ningún voto es válido con menos de cinco asientos ocupados. Los cambios normativos se aprueban con mayoría de todos los asientos, no de los presentes, y la ratificación de una versión exige dos tercios de todos los asientos. Las actas se publican, y una opinión minoritaria se publica íntegra en el changelog — un disenso que el público puede leer vale más que una unanimidad que no puede verificar.
7. Los asientos se llenan por nominación pública: las candidaturas y sus divulgaciones se publican por al menos treinta días antes de sentar a alguien. Hasta llenar cinco asientos, una candidatura publicada sin oposición se sienta tras sus treinta días; del sexto asiento en adelante, sentar exige mayoría del Board en funciones. El Editor puede proponer candidatos; el Editor no nombra a nadie.
8. Las revisiones de notas y doctrina hechas entre versiones se presentan en cada reunión del Board, y cualquiera puede revertirse por mayoría simple. Las notas son el canal del Editor; el Board sostiene la puerta.
9. El Editor sirve hasta su renuncia o remoción por dos tercios de todos los asientos, y el Board nombra al sucesor. El fundador escribió el estándar; el cargo lo sobrevive.

### Proceso de enmienda

1. Cualquiera propone un cambio, públicamente, con el razonamiento y el caso que lo motivó.
2. El Editor responde en noventa días: un borrador de enmienda o una negativa razonada, ambos publicados.
3. La negativa no es veto. Tres miembros del Board pueden patrocinar una propuesta directo a consulta y voto, sin borrador del Editor.
4. La consulta pública corre al menos treinta días antes de cualquier voto sobre texto normativo.
5. El Board vota bajo las reglas del Board: los cambios normativos se aprueban con mayoría de todos los asientos — y el Editor tiene voz, mas no voto.
6. El changelog registra qué cambió, quién lo propuso, el conteo del voto, y toda opinión minoritaria íntegra.

### Estado actual

La Candidate 1.0 es una propuesta de un solo autor. El Standard Review Board está en formación y cada uno de los nueve asientos está abierto. Publicarlo así es una decisión deliberada: un estándar que admite ser una propuesta es más creíble que uno que insinúa una institución que todavía no tiene. Y sigue siendo candidata hasta que un Board constituido bajo estas reglas la ratifique como versión 1.0 — el autor no puede ratificar su propio estándar. Si alguno de los nueve asientos lo describe, la invitación está abierta.

### El congelamiento

La Candidate 1.0 se congeló el 1 de septiembre de 2026 a las 00:00 UTC sin Board constituido — como la regla decía que ocurriría, hubiera o no. Desde ese momento el autor deja de editar el texto normativo — no «deja de editarlo salvo correcciones menores», sino deja de editarlo. Un estándar cuyo autor lo sigue parchando en silencio no es un estándar: es un documento personal con pretensiones. Lo que sigue es el mecanismo que vuelve el congelamiento verificable en lugar de retórico, y debajo el registro de la única revisión emitida desde entonces.

**Qué identifica la versión congelada.** Una fecha y hora en UTC, una etiqueta de versión y un hash del contenido de la edición canónica legible por máquinas, publicados en esta página. La salida del libro que lo acompaña no es el disparador: un libro tiene fechas distintas por formato y por mercado, y un evento normativo no puede depender de una tienda.

**Erratas, que nunca cambian una obligación.** Erratas tipográficas, enlaces rotos, errores de traducción y errores de hecho en las notas se registran en una lista pública de erratas con su fecha. El texto congelado no se edita: el registro vive al lado. Todo lo que alteraría lo que un deployment debe hacer no es errata — es enmienda, y las enmiendas esperan al Board.

**Deprecación de emergencia.** Si un defecto del texto congelado pudiera causar daño material — un error de seguridad, jurídico o de integridad —, el Editor puede deprecar la versión completa, en público y con motivos, y marcarla como no utilizable para nuevas declaraciones de conformidad. La deprecación es la única palanca unilateral, y es tosca a propósito: puede retirar una versión, nunca reescribirla. Las ediciones unilaterales quirúrgicas son justamente lo que el congelamiento existe para impedir.

**Si el Board nunca alcanza quórum.** El texto congelado sigue siendo válido y citable, y sigue siendo Candidate. No se convierte en 1.0 en silencio por el paso del tiempo, y no vuelve a manos del autor. Un estándar que nadie ratificó sigue siendo una especificación utilizable — solo que nunca gana la palabra que dice que un cuerpo lo examinó.

La asimetría es deliberada. Retirar una versión exige una persona y un motivo público; cambiarla exige un Board. Que sea fácil detener y difícil alterar es lo que impide que el congelamiento sea una pose.

### Hallazgos abiertos — en espera del Board

Hallazgos de la revisión adversarial de Candidate 1.0 que sobrevivieron la verificación en parte pero no fueron enmendados por el Editor en solitario. Se publican en vez de archivarse, porque un estándar que esconde sus huecos conocidos es marketing: cada uno es agenda del Board, y cada uno sigue listado aquí hasta que una versión lo resuelva.

1. Un piso legal para la clasificación de riesgo: los usos prohibidos o enumerados como de alto riesgo por la ley aplicable deberían entrar al nivel correspondiente como un piso que los siete factores pueden subir pero nunca bajar.
2. Ponderación independiente de las retenciones de explicación: donde aplica la ley de protección de datos, el material de secreto comercial va a una autoridad o corte para ponderarse (CJEU C-203/22) — la retención registrada de HWF-04 es el mecanismo de este estándar, no un cumplimiento de esa ley.
3. Una prueba de materialidad con ejemplos resueltos para las materias reservadas de HWF-02, para distinguir operaciones rutinarias que tocan cuentas reservadas de decisiones reservadas.
4. Una cláusula de recepción: un canal de quejas, una ventana de respuesta y un proceso de incidentes graduado por severidad con dueño con nombre, como precondiciones del go-live — los derechos de HWF-04 necesitan una puerta donde tocar.
5. Una fuente definida para las métricas de calidad de escalación: una revisión por muestreo de casos no escalados con tasa mínima y revisor con nombre fijados por clase de riesgo, para que cero fallas reportadas signifique algo.
6. Referencias cruzadas a las evaluaciones de impacto legales — la de derechos fundamentales del Artículo 27 del EU AI Act y regímenes análogos — declarando expresamente que HWF-03 no las satisface.
7. Missed Escalation Rate normalizado por profundidad de muestreo de auditoría, reportado como par, con la graduación de severidad a cargo de una parte independiente del presupuesto de revisión que justifica.
8. Cómputo solo agregado de las métricas del scorecard que tocan humanos con nombre, con el acceso a nivel individual compuertado bajo la prueba de propósito nuevo de HWF-42.

## Licencia

Creative Commons Atribución-CompartirIgual 4.0 Internacional (`CC-BY-SA-4.0`) — https://creativecommons.org/licenses/by-sa/4.0/

Puede citar, embeber, enseñar, traducir y usar comercialmente este material con atribución. Una versión modificada debe llevar la misma licencia. Los nombres «Hybrid Workforce Standard», «HybridWF», «HWF», «WRM» y «HWFA» (antes HWFS) y los esquemas de identificadores HWF-/G- quedan reservados y no están licenciados: puede declarar que su trabajo conforma con el estándar, pero no publicar una versión modificada con el mismo nombre, operar un programa de certificación o insignias invocándolo, ni reutilizar sus identificadores de cláusula para texto alterado — una versión modificada renumera sus cláusulas.

## Fuentes

### Mercado y proveedores

| ID | Fuente |
| --- | --- |
| S1 | [Lattice — “Leading the Way in Responsible AI Employment” (9 Jul 2024)](https://lattice.com/blog/leading-the-way-in-responsible-ai-employment) |
| S2 | [SHRM — Lattice scraps plans to treat AI bots as employees after backlash (Jul 2024)](https://www.shrm.org/topics-tools/news/technology/lattice-scraps-plans-to-treat-ai-bots-as-employees-after-backlash) |
| S3 | [Salesforce — What Is Digital Labor? / Agentforce positioning](https://www.salesforce.com/agentforce/digital-labor/) |
| S4 | [Microsoft — Six core capabilities to scale agent adoption in 2026](https://www.microsoft.com/en-us/microsoft-copilot/blog/copilot-studio/6-core-capabilities-to-scale-agent-adoption-in-2026/) |
| S5 | [Microsoft — Introducing Microsoft Scout / Autopilots, always-on agents (2 Jun 2026)](https://www.microsoft.com/en-us/microsoft-365/blog/2026/06/02/introducing-microsoft-scout-your-always-on-personal-agent/) |
| S6 | [ianai — AI Employee / role-based authority and persistent digital worker](https://www.ianai.co/) |
| S7 | [AIEmployee.com — AI Employee platform](https://home.aiemployee.com/) |
| S8 | [GIZIN — AI collaboration / AI Employees](https://gizin.co.jp/) |

### Estándares e instituciones

| ID | Fuente |
| --- | --- |
| S9 | [ISO 30414:2025 — Human resource management, HCRD](https://www.iso.org/standard/30414) |
| S10 | [ISO/TC 260 — Human resource management standards catalogue](https://www.iso.org/committee/628737/x/catalogue/p/1/u/0/w/0/d/0/) |
| S11 | [CIPD — Performance Management factsheet](https://www.cipd.org/en/knowledge/factsheets/performance-factsheet/) |
| S12 | [CIPD — Line managers’ role in supporting the people profession](https://www.cipd.org/uk/knowledge/factsheets/line-managers-factsheet/) |
| S13 | [ILO — Safe and healthy working environment as a fundamental principle and right](https://www.ilo.org/topics-and-sectors/safety-and-health-work/safe-and-healthy-working-environment-fundamental-principle-and-right-work) |
| S14 | [NIST — AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) |
| S15 | [NIST — AI RMF Playbook](https://airc.nist.gov/airmf-resources/playbook/) |
| S24 | [OECD — AI Principles (human-centred values: dignity, autonomy, social justice, labour rights)](https://oecd.ai/en/ai-principles) |
| S25 | [EU — Artificial Intelligence Act: regulatory framework on AI (risk-based approach)](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) |
| S26 | [EU — GDPR Article 22: automated individual decision-making](https://gdpr-info.eu/art-22-gdpr/) |
| S27 | [EU — AI Act Article 26: obligations of deployers of high-risk AI systems (worker information)](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26) |
| S28 | [EU — AI Act Article 86: right to explanation of individual decision-making](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-86) |
| S30 | [EU — AI Act Article 50: transparency obligations for AI interacting with people (Commission FAQ)](https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act) |
| S31 | [EU — GDPR Article 5: principles relating to processing of personal data](https://gdpr-info.eu/art-5-gdpr/) |
| S32 | [ISO/IEC 42001 — Artificial intelligence management system](https://www.iso.org/standard/42001) |
| S33 | [ISO/IEC 42005 — AI system impact assessment](https://www.iso.org/standard/42005) |

### Señales académicas

| ID | Fuente |
| --- | --- |
| S16 | [Johnston et al. — The Shift to Agentic AI: Evidence from Codex (2026)](https://arxiv.org/abs/2606.26959) |
| S17 | [Liu — The Organizational Behavior of Agentic AI (2026)](https://arxiv.org/abs/2606.30986) |
| S18 | [Agentic Business Process Management: A Research Manifesto (2026)](https://arxiv.org/html/2603.18916v3) |
| S19 | [Alenezi — Human-AI Collaboration and the Transformation of Software Engineering Work (2026)](https://arxiv.org/abs/2606.03394) |
| S20 | [Intelligent AI Delegation (2026)](https://arxiv.org/html/2602.11865v1) |
| S29 | [Elish — Moral Crumple Zones: Cautionary Tales in Human-Robot Interaction (2019)](https://estsjournal.org/index.php/ests/article/view/260) |

### Libros y obras competidoras

| ID | Fuente |
| --- | --- |
| S21 | [GIZIN — AI Employee Starter Book](https://store.gizin.co.jp/en/ai-employee-book) |
| S22 | [GIZIN — AI Employee Master Book](https://store.gizin.co.jp/en/ai-employee-master) |
| S23 | [B. Jaiswal — AI EMPLOYEE: How One Person Does the Work of Ten (Jun 2026)](https://play.google.com/store/books/details/B_JAISWAL_AI_EMPLOYEE?id=0w3uEQAAQBAJ) |
| S34 | [M. J. Phillips — AI Employee: How to Design, Onboard, and Lead the New Hybrid Workforce (Sep 2026) — the companion to this standard](https://masterjoephillips.com/libros/ai-employee-en.pdf) |
| S35 | [M. J. Phillips — Empleado IA (Ago 2026) — el acompañante de este estándar](https://masterjoephillips.com/libros/empleado-ia-es.pdf) |

### Límites metodológicos

1. La investigación de mercado representa un corte al 9 de agosto de 2026. El posicionamiento y las capacidades de producto cambian rápidamente.
2. Las afirmaciones de vendors se interpretan como posicionamiento de producto, no como validación independiente de performance. Eso incluye la plataforma del propio autor.
3. La matriz de 120 principios es una síntesis propia inspirada en disciplinas de RR. HH., management, workforce analytics, seguridad y riesgo. No pretende atribuir esos principios a una única organización.
4. ISO 30414:2025 y el catálogo ISO/TC 260 se usan como evidencia de que la gestión de recursos humanos comprende múltiples áreas medibles y estandarizables; CIPD para performance y line management; OIT para fronteras de derechos humanos; NIST para gobierno de riesgo de IA. Ninguna de esas instituciones respalda este estándar.
5. Los papers de arXiv son preprints salvo que se indique otra cosa, y se usan como señales de investigación emergente, no como consenso científico definitivo.
6. La definición, el test de nueve propiedades, el modelo de madurez, los playbooks de transición, el HWFA y este mismo estándar son propuestas conceptuales desarrolladas en este trabajo. No son estándares oficiales de ISO, NIST, la OIT ni de ningún proveedor citado.

### Linaje conceptual

- Henri Fayol — unidad de mando, autoridad/responsabilidad, división del trabajo.
- Peter Drucker — dirección por objetivos, efectividad y responsabilidad gerencial.
- W. Edwards Deming — medición, sistema, variación y mejora continua.
- Dave Ulrich y la tradición moderna de human resource management — diseño del talento y capacidad organizacional.
- Prácticas contemporáneas de performance management, diseño organizacional, RBAC, least privilege, segregación de funciones y gestión de riesgo empresarial.

## Cambios

### Candidate 1.0.1 · 2026-09-12 · Revisión editorial de la edición en inglés — emitida por el Editor, pendiente de ratificación del Board

- Siete cláusulas se enmendaron por vocabulario, no por significado: «post» pasa a «position» en toda la edición en inglés — HWF-02, 03, 23, 41, 51, 61 y 63 en texto de cláusula, más el glosario, la matriz WRM y el HWFA — y «dismissal» pasa a «termination» en HWF-02. «Post» con sentido de puesto es uso británico que un lector estadounidense lee primero como publicación; «position» conserva el sentido y deja intacta la distinción de la que depende este estándar, entre el puesto (la casilla) y el rol (la función). La edición en español no cambia: «puesto» y «rol» ya cargaban esa distinción. Nada de lo que un deployment conforme debe hacer se movió.
- La edición en inglés pasa a grafía estadounidense — 176 palabras en el texto canónico. El cambio es editorial: ninguna cláusula cambió lo que un deployment conforme debe hacer. Los nombres propios y los instrumentos citados conservan la grafía de su fuente, así que los principios de la OCDE citados aquí se siguen leyendo como los escribió la OCDE. La convención queda enunciada en «Cómo leer este estándar», para que enmiendas posteriores no deriven hacia una segunda variante.
- Con esta revisión viaja una errata. La Candidate 1.0 describía su propio glosario como de cuarenta y un términos; tiene cuarenta y dos, G-01 a G-42 sin huecos, y ya tenía cuarenta y dos al congelarse. El conteo se corrige acá y la edición congelada conserva el número equivocado, porque un texto congelado no se edita — la corrección vive al lado. Aparece en una nota, nunca en texto de cláusula, y ninguna obligación depende de ella.
- Esta revisión la emitió el Editor sin Board, porque después del congelamiento los cambios de texto de cláusula exigen votación y ninguno de los nueve asientos está ocupado. Queda registrada acá, en el registro congelado y en el historial de commits en vez de aplicarse en silencio: el congelamiento existe para impedir que un autor parche su propio texto a escondidas, y publicar la falta es la única versión de esto que deja la regla en pie. La Candidate 1.0 sigue congelada y citable en su dirección permanente, con hash publicado. Un Board, una vez constituido, puede ratificar, enmendar o revertir esta revisión.

### Candidate 1.0 · 2026-08-12 · Congelada el 1 de septiembre de 2026 a las 00:00 UTC — pendiente de ratificación del Board

- Candidate 1.0: veintisiete cláusulas normativas en ocho bloques — 0x fundamento humano a 7x conformidad — más el test de nueve propiedades, el marco WRM con su matriz de 120 principios, el modelo de madurez, el instrumento de asignación HWFA, la clasificación de riesgo de cinco niveles, el rol de Gerente de Fuerza Laboral Híbrida, los playbooks de transición y un glosario de cuarenta y dos términos. Publicado bilingüe, con el texto completo como un archivo legible por máquinas por idioma.
- La certificación está deliberadamente fuera del alcance y no regresa: el autor tiene un interés comercial en la categoría, así que el estándar no puntúa productos, no emite sellos, y convierte la conformidad en una autodeclaración que cualquiera puede verificar o refutar — escrutinio público, estructura en vez de confianza.
- El frente carga el preámbulo — la declaración del documento mismo —, la motivación y el objetivo estratégico firmados por el autor, la tesis corregida durante la redacción para que termine donde termina toda cadena (un Empleado IA ocupa un rol; un humano responde por él), y la fórmula invariante: la IA ejecuta, la organización responde, un humano gobierna.
- La gobernanza se reformó antes de llenar asiento alguno: nueve asientos con mayoría practicante y un solo académico; interés comercial con tope de dos asientos, con divulgación y recusación juzgada por los no conflictuados; honorario transparente, idéntico y publicado; nominación pública donde el Editor propone y no nombra a nadie; quorum de dos tercios sobre asientos ocupados y mayorías normativas contadas sobre todos los asientos; reversión por el Board de revisiones de notas; sucesión y remoción del Editor — y la regla más profunda: el Editor tiene voz, mas no voto. La publicación sigue siendo candidata hasta que un Board constituido bajo estas reglas la ratifique; el autor no puede ratificar su propio estándar.
- El instrumento de asignación es el HWFA — antes Fit Score, renombrado porque un instrumento que deliberadamente se niega a producir un número no debería llamarse Score. Corre en tres etapas que encarnan el orden de HWF-01 (elegibilidad, luego riesgo, luego economía), puede responder automatización determinista — no se necesita un Empleado IA — y devuelve un argumento en vez de un número, porque un puntaje permitiría lavar por aritmética una decisión ya tomada.
- Los números de cláusula cargan la arquitectura: el primer dígito nombra el bloque, el bloque 0 es el fundamento humano, y HWF-01 es la cláusula suprema — número y rango alineados. Una cláusula nueva toma el siguiente número libre en la decena de su bloque; un bloque que llega a nueve cláusulas está pidiendo partirse en una versión mayor, no extenderse.
- Candidate 1.0 se revisó adversarialmente antes de que existiera Board alguno: veinte recomendaciones externas y un concilio de cinco asesores con refutación de pares anónima — cuarenta hallazgos. Todo lo confirmado se enmendó; siete ataques murieron contra texto existente; y ocho hallazgos confirmados en parte se publican como hallazgos abiertos, agenda del Board hasta que una versión los resuelva — porque un estándar que esconde sus huecos conocidos es marketing. Las consideraciones por cláusula que sobrevivieron ese proceso quedan registradas abajo.

Desde el congelamiento, cambiar el texto de una cláusula exige subir de versión y una votación del Board, y toda versión congelada permanece en su propia dirección permanente para que una cita hecha entonces siga resolviendo en cinco años. Hasta el congelamiento, la Candidate es un borrador: su texto puede enmendarse bajo custodia editorial, y el registro con autoridad de cada enmienda — fecha, texto anterior, texto nuevo y motivo — es el historial público de commits del repositorio. Notas, ejemplos y comentario pueden corregirse entre versiones sin enmendar el estándar. El primer dígito del número de una cláusula nombra su bloque, así que una cláusula nueva toma el siguiente número libre dentro de la decena de su bloque — el orden temático y la estabilidad de citas ya no se intercambian. Un bloque que llega a nueve cláusulas no está pidiendo una décima; está pidiendo partirse, y partir bloques es trabajo de versión mayor para el Board. Dentro de una versión, las entradas del changelog son historia de redacción en orden cronológico inverso: donde varias tocan la misma cláusula, gobierna el relato más nuevo y las anteriores quedan como registro.

### El registro congelado

Lo que identifica a una versión congelada es una fecha y hora en UTC, una etiqueta de versión y un hash de contenido de la edición canónica legible por máquinas. Acá están. El hash cubre el archivo tal como quedó en el congelamiento: recalcúlelo contra la copia archivada y debe coincidir, o esta página está equivocada.

- **Candidate 1.0** — 2026-09-01T00:00:00Z
  - https://hybridwf.com/1.0/standard.md (Inglés) — sha256 `a88007a1b01851a5236d04abccf174b041023549d5d3cb1fe950e2c1f2161944`
  - https://hybridwf.com/1.0/estandar.md (Español) — sha256 `04ef2c5e1bb9610841cd507ff37abc86ee8059424578c0d96006a4d865897662`

### La revisión emitida después del congelamiento

La Candidate 1.0.1 es una revisión editorial de la edición en inglés, emitida después del congelamiento. Cambia terminología y grafía, y ninguna obligación: «post» pasó a «position», «dismissal» pasó a «termination», y la grafía británica pasó a estadounidense. Catorce de las veintisiete cláusulas tienen texto citable alterado — siete por vocabulario, siete solo por grafía — y la 1.0 archivada abajo es contra lo que se verifican. Bajo la regla de arriba, los cambios de texto de cláusula después del congelamiento exigen una votación del Board, y no hay Board que pueda sostenerla. El Editor emitió esta revisión en solitario, y la registra acá en vez de editar en silencio — el parchado silencioso es exactamente la falla que el congelamiento fue escrito para impedir, y una regla rota a la vista sigue siendo una regla. La Candidate 1.0 sigue congelada, citable y archivada en su propia dirección, y la edición en español con la que se congeló no cambia. Un Board, una vez constituido, puede ratificar esta revisión, enmendarla o revertirla.

### Consideraciones por cláusula

Una entrada por cláusula: las consideraciones que la produjeron, conservadas después de quitar el ruido de redacción. Esto es por qué cada cláusula dice lo que dice — la parte del registro que un Board futuro va a necesitar.

**0 · Fundamento humano**

- **HWF-01** — Las personas son fines; el software es un medio. La neutralidad de recurso es disciplina de asignación, no postura moral, así que las restricciones son léxicamente prioritarias: el costo optimiza dentro del espacio que dejan abierto los derechos, la dignidad, la seguridad, la agencia, la accesibilidad y las protecciones laborales, y nunca se intercambia contra ellas. La cláusula no promete que el desplazamiento no ocurrirá; gobierna los términos, como hizo la legislación laboral con el tractor — y tiene precedencia sobre toda otra cláusula.
- **HWF-02** — Las decisiones reservadas son un piso por materia, porque clasificar es juicio y el juicio puede estar motivado. La participación artificial — análisis, redacción, recomendación — sigue siendo legal; la decisión no. La prueba de decidir es operativa: un humano que no puede reformular el caso y decidir distinto está firmando, no decidiendo. Una decisión reservada es Crítica por definición.
- **HWF-03** — Ninguna transformación material sin evaluación de impacto humano registrada, consultada antes, no después. Sus dimensiones menos reportadas: el deskilling — automatizar el trabajo junior y dejar de producir seniors — y la carga de excepciones que queda en humanos cuando la automatización absorbe los casos fáciles. La consulta no es consentimiento, y no se exige conclusión favorable: una evaluación obligada a bendecir la transición sería teatro.
- **HWF-04** — Las personas afectadas tienen siete derechos frente al deployment. La explicación debida es evidencia operacional — política, datos, herramientas, autoridad — nunca una transcripción de razonamiento: la evidencia operacional es disputable, y nadie puede impugnar una vibra. La entrega corre por criterio humano, toda retención se registra, y la confidencialidad estrecha una explicación pero nunca cancela el deber de dar una accionable.

**1 · La categoría**

- **HWF-11** — Un rol, no una personalidad: el puesto existe antes que su ocupante, con resultado, autoridad y medición. Antes no significa congelado — los ocupantes remodelan puestos legítimamente, y toda remodelación se declara, porque el puesto declarado es la interfaz: un colega humano lee un rol no declarado desde el pasillo; uno artificial solo puede leer el grafo.
- **HWF-12** — El test es conjuntivo en ambas direcciones. Faltando una propiedad, el sistema es un agente — respetable, pero no un Empleado IA. Exhibiendo las nueve en operación, lo es se llame como se llame, con la carga de la no-calificación en el deployer: un contrato de rol sin escribir es una falla de gobierno, no una salida de la categoría. Y el incumplimiento se queda dentro de la categoría — una definición que expulsara infractores dejaría al estándar sin nada que obligar.
- **HWF-13** — La cláusula de estatus practica modestia epistémica: no se reconoce personería, relación laboral, conciencia ni estatus moral — y nada se niega. No-reconocimiento en la postura del derecho societario. Cada cláusula se sostiene como sea que algún día se resuelva la filosofía de la mente, porque ninguna depende de la respuesta.
- **HWF-14** — El engaño se prohíbe por resultados observables, no intenciones, porque la intención no es auditable: hacerse pasar por humano; declarar sentimientos; señales razonablemente capaces de inducir creencia falsa; optimización contra objetivos registrados de dependencia emocional; intervención artificial ocultada. Divulgación al inicio, renovada en puntos materiales. La cortesía y la personalización siguen siendo legales — nada exige que un Empleado IA escriba mal.

**2 · Accountability**

- **HWF-21** — Exactamente un accountable owner — primario, no exclusivo. La supervisión puede delegarse, incluso a otro Empleado IA; la accountability no, porque responder por un resultado exige capacidad de cargar una consecuencia. Las obligaciones de sistema, datos, seguridad, proveedor y directores sobreviven intactas, y un cuerpo de gobierno califica como terminus solo con presidente identificado, reglas de decisión declaradas y capacidad de emergencia.
- **HWF-22** — Las cadenas pueden ser profundas, pero deben ser recorribles, observables e interrumpibles sin pasar por sí mismas: quien responde y debe pedirle permiso a la pirámide tiene una petición, no control. La escala solo crece contra tooling — mil recursos sin instrumentos son un organigrama, no accountability.
- **HWF-23** — La ownership es una capacidad dotada, no un nombre en un campo: competencia, autoridad, tiempo para el alcance, acceso a evidencia, independencia de las presiones dueñas del resultado, poder de suspender, entrenamiento contra el sesgo de automatización. El kill switch se ejercita con cadencia declarada — nunca jalado es decoración — y la zona de absorción queda prohibida: la culpa sigue a los determinantes, no a la proximidad.

**3 · Autoridad y control operativo**

- **HWF-31** — La autoridad debe ser explícita, limitada y revocable — escrita antes de que el recurso opere, nunca inferida después a partir de lo que hizo.
- **HWF-32** — Mínimo privilegio, porque el acceso es capacidad y superficie de riesgo a la vez: más acceso no es más competencia; es un radio de daño más grande.
- **HWF-33** — Las acciones de alto riesgo soportan aprobación humana, con proporcionalidad y separación de funciones — quien inicia no aprueba. Qué cuenta como alto riesgo se resuelve contra la clasificación de HWF-51, no contra el gusto.
- **HWF-34** — Escalar en vez de improvisar: una respuesta convincente donde debía haber una duda escalada es la falla más peligrosa. Toda excepción necesita un destino — y ninguna métrica puede castigar el viaje, porque un sistema premiado por escalar menos aprende silencio.
- **HWF-35** — Retener contexto es una decisión de diseño legítima en ambas direcciones — proteger la información, o prevenir la degradación medible de la decisión (anclaje, contaminación, saturación) — y toda restricción es un registro de frontera de contexto, versionado y auditable. La responsabilidad por una decisión degradada por contexto retenido recae en quien lo retuvo.

**4 · Evidencia y datos**

- **HWF-41** — La auditoría reconstruye los determinantes de una decisión — política, conocimiento, resultados de herramientas, autoridad, versiones — y no solo su resultado, porque una auditoría de solo-qué deja cinco fallas distintas viendo idénticas. El relato del modelo sobre su propio razonamiento puede apoyar la reconstrucción y nunca la sustituye. La materialidad escala por clase de riesgo: correlacionar logs contra el manifiesto de versiones es conforme para puestos Bajos y Moderados.
- **HWF-42** — La memoria es un sistema de datos entre varios: inputs, outputs, resultados de herramientas e inferencias derivadas se gobiernan enteros — finalidad, base, minimización, transferencias, uso del proveedor incluido el entrenamiento, aislamiento, eliminación verificable. Una inferencia que la persona nunca entregó sigue siendo su dato. Y el registro de auditoría es él mismo uno de estos sistemas, gobernado con la misma severidad que la operación que audita: minarlo para puntuar empleados es un propósito nuevo que exige base propia.
- **HWF-43** — Una versión identificable de modelo, políticas, herramientas y conocimiento — porque sin ella, ni la reconstrucción de HWF-41 ni la revalidación de HWF-52 tienen objeto.
- **HWF-44** — El desempeño se mide por outcomes, calidad, riesgo y costo — nunca actividad, horas, tokens ni volumen de mensajes: la velocidad puede hacer que el movimiento parezca valor.

**5 · Riesgo y validación**

- **HWF-51** — Cinco niveles juzgados sobre riesgo inherente con siete factores — nunca solo el costo del error, porque un error barato a escala contra personas vulnerables no es un error barato. Los controles bajan el residual, nunca la clase: un guardrail no puede comprar un mejor nivel. Crítico termina siempre en decisión humana final; Prohibido no puede volverse conforme con ningún control. Interopera con la ley basada en riesgo sin afirmar equivalencia.
- **HWF-52** — Una versión es un registro, no una prueba: todo cambio material se revalida antes de operar, a profundidad escalada por clase — el playbook compuerta el nacimiento; esta cláusula mantiene ganada la transición. La automatización determinista no se toca porque la categoría la excluye. Los equipos agregan riesgos sistémicos, la falla correlacionada ante todo: cien humanos se equivocan de cien maneras; cien instancias de un mismo modelo se equivocan idénticamente y a la vez.

**6 · Ciclo de vida**

- **HWF-61** — El defecto más común de un contrato de rol no es la mala redacción sino el abandono: la revisión carga techo de doce meses, y toda obligación con reloj vive en un calendario de gobernanza con un solo dueño. El monitoreo independiente contra el contrato es el control primario; el auto-reporte del recurso lo complementa — un sistema cuya configuración es el problema comparte el punto ciego. Cambiar el contrato es siempre decisión humana.
- **HWF-62** — Toda transición es evaluable contra un baseline registrado antes del cambio — de lo contrario la organización celebra una mejora que nunca ocurrió — y los criterios de rollback se escriben antes de conocer los resultados, porque los criterios escritos después son justificación.
- **HWF-63** — Ningún puesto sobrevive a su justificación: la existencia se re-justifica con cadencia, antes y aparte del desempeño, porque cumplir todos los KPIs en un puesto que nadie necesita es el anestésico habitual. Los disparadores débiles que a veces podan puestos humanos — una línea de salario, una renuncia — no existen para los artificiales, y eso es lo que acumula zombis digitales. Una revisión vencida restringe o suspende en proporción; el retiro sigue a una justificación fallida, nunca a un calendario perdido.
- **HWF-64** — El offboarding es tan importante como el onboarding y casi siempre se omite: revocar, deshabilitar, rotar, transferir, preservar evidencia — un puesto retirado cuyos accesos lo sobreviven es superficie de riesgo sin retorno.

**7 · Conformidad**

- **HWF-71** — La conformidad pertenece a un deployment — nunca a un producto, plataforma ni organización en abstracto, y la primera plataforma atada es la del propio autor. Nueve campos publicados; evaluación de alcance completo o el claim se rotula parcial; validez máxima de doce meses; el claim de habilitación exige una declaración de cliente viva y enlazada públicamente. Una declaración publicada es una representación comercial accionable: sustanciar antes de publicar, retirar pronto al vencer.