Un colaborador nuevo lleva tres semanas en el puesto. Su manager lo llama porque autorizó algo que no debía: le prometió a un cliente una entrega para el viernes. «Me preguntó cuándo, y el viernes me pareció razonable. Son cinco días», explica. «Ese producto lleva tres semanas. Siempre», responde el manager. «No lo sabía. ¿Dónde está eso escrito?». Y llega la respuesta que retrata a media organización: «Todo el mundo lo sabe».
Nadie actúa de mala fe, y esa es exactamente la cuestión. El manager tiene razón en el fondo: la fecha era imposible. El colaborador tiene razón en la forma: nadie se lo dijo, y actuó con el criterio que pudo construir. La conversación termina con el manager concluyendo que el nuevo «no tiene criterio»: la conclusión más cómoda y la menos útil.
Ahora reemplazá al colaborador por un recurso artificial y el intercambio se vuelve imposible. El sistema no va a preguntar dónde está eso escrito. Simplemente va a seguir prometiendo viernes.
El juicio imposible de ganar
Muchas implementaciones de IA reproducen ese primer día. El agente recibe acceso, una instrucción general y una expectativa desproporcionada. No conoce las excepciones históricas ni la jerarquía de prioridades, y no sabe cuál decisión requiere aprobación. Entonces la organización lo somete a un juicio que no puede ganar: si pregunta demasiado, decimos que no es autónomo; si decide y falla, decimos que no es confiable. En realidad le exigimos desempeño dentro de un puesto que nunca diseñamos.
El patrón se ve a escala. Un informe del proyecto NANDA, del MIT Media Lab, estudió iniciativas empresariales de IA generativa y encontró que la enorme mayoría no producía retorno medible. Su cifra más citada, el 95% sin retorno, fue muy discutida, y el libro no descansa en ella. Lo que resiste el debate es el diagnóstico: los sistemas no retenían contexto, no recordaban lo aprendido y no se adaptaban al flujo de trabajo real. El informe llamó a eso la brecha de aprendizaje. Es la descripción exacta de un colaborador al que nadie incorporó.
¿Contratarías a una persona diciéndole solamente «ayudá a ventas y hacelo bien»? Le explicarías qué resultado debe producir, qué promesas requieren aprobación y a quién acudir ante una excepción. Un prompt puede orientar una ejecución. No reemplaza el diseño de un puesto.
Un prompt da instrucciones. Un puesto da responsabilidad.
Un contrato operacional, no una pieza legal
El instrumento que convierte una intención tecnológica en una unidad de trabajo administrable es el AI Role Contract, el contrato de rol: el documento central de todo el método. No pretende humanizar software ni tiene ambición jurídica: es la combinación funcional de una buena descripción de puesto y un acuerdo explícito de operación, para convertir capacidad tecnológica en responsabilidad administrable.
Recorramos sus piezas con el hilo que usa el libro: la responsabilidad de recordatorios de cobranza que el HWFA asignó a un ocupante artificial.
Las piezas del contrato
Misión y resultados
Para qué existe el rol y qué valor debe producir. No una lista de movimientos: un propósito. El libro lo ejemplifica así: «Convertir facturación vencida temprana en pagos, protegiendo la relación con el cliente, para las cuentas de menos de 45 días de atraso.» Una misión bien escrita ya excluye cosas: este rol no negocia acuerdos, no toca cuentas mayores a 45 días, no decide sobre clientes en disputa. Cada resultado necesita indicadores, y un buen KPI también vigila lo que no debe pasar: «cero contactos a cuentas marcadas en disputa» es tan medible como una tasa de respuesta.
Autoridad y exclusiones
Qué puede consultar, crear, modificar, comunicar, aprobar, comprometer o gastar. En la práctica es una tabla, y su valor está en la incomodidad de escribirla. Puede: consultar saldos, enviar recordatorios desde plantillas aprobadas, registrar promesas de pago. No puede: ofrecer descuentos ni condonaciones, modificar fechas de vencimiento, comprometer planes de pago, contactar cuentas en disputa. Las exclusiones son tan importantes como los permisos. Responsabilidad y autoridad viajan juntas: no podés exigir accountability donde nunca definiste autoridad.
Escalamiento
Toda excepción necesita un destino: una persona, un equipo o una regla de retorno. Cliente responde con reclamo o disputa: transfiere a la analista con el expediente completo, antes de dos horas hábiles. Cliente menciona dificultad económica seria: detiene la secuencia y marca para manejo humano. Un rol sin destinos de escalamiento no tiene excepciones gobernadas. Tiene excepciones enterradas.
Suspensión y kill switch
Si el error supera cierta banda, ocurre un incidente o desaparece una dependencia crítica, el manager debe saber cuándo reducir autonomía o detener el rol. El kill switch sin responsable es apenas una función técnica; el contrato define quién puede utilizarlo y bajo qué condición. Y un interruptor que nunca se ha probado es decoración.
Calendario de gobernanza y versionado
Todo lo que tiene reloj en la vida del rol vive en una sola sección con fechas y un solo dueño del cronograma: la revisión del contrato, la re-justificación del puesto, los simulacros del kill switch, las revalidaciones tras cambios. Sin calendario consolidado, cada obligación tiene una fecha y ninguna tiene un responsable. El contrato además se versiona, porque el puesto cambia con productos, políticas, modelos y riesgos. La cláusula HWF-61 le pone tope al reloj: el contrato se revisa con cadencia declarada, nunca mayor a doce meses, y la decisión de cambiarlo es siempre humana.
Exactamente un dueño
El contrato identifica al accountable owner: el humano que responde por el diseño y el desempeño del rol. El estándar es quirúrgico con esta figura, y conviene heredar su precisión completa.
Primero: exactamente uno. Un rol con dos dueños no tiene ninguno, y «el área de finanzas» no responde por nada. Las áreas no firman. Puede ser una persona con nombre o un cuerpo humano de gobierno, pero un comité solo cuenta como dueño si tiene presidente identificado, reglas de decisión declaradas y capacidad de actuar en una emergencia. Sin esas tres cosas no es un owner: es un mecanismo para difuminar la culpa.
Segundo: no confundás al owner con el supervisor. Supervisar (rutear casos, revisar salidas, priorizar, recibir excepciones) es trabajo, y puede delegarse, incluso a otro recurso artificial. La accountability no se delega jamás: toda cadena de supervisión, tenga los eslabones que tenga, termina en ese humano o cuerpo identificado.
Tercero: uno es primario, no exclusivo. El owner no extingue las obligaciones del dueño de seguridad, del responsable de datos ni del proveedor. Responde «¿quién responde por este recurso?», no «¿quién más tiene deberes?».
Un Empleado IA con credenciales reales, canales oficiales y capacidad de comprometer a la empresa, pero sin misión declarada, sin exclusiones escritas, sin destino de escalamiento y sin dueño identificado, no es una apuesta audaz. Es un incidente esperando fecha. La única incógnita es el día.
Del papel a la operación
Un contrato bien escrito todavía no trabaja. Queda una verificación que casi nadie hace y que separa el diseño serio del optimista: probar que la autoridad definida en papel coincide con los permisos reales. Un recurso puede tener prohibido aprobar descuentos en su contrato y conservar, por error, una credencial que se lo permite. En el sentido contrario, puede responder por un KPI sin acceso a la información necesaria para medirlo. La distancia entre el contrato y la configuración es exactamente el espacio donde viven los incidentes.
Y el contrato define la responsabilidad, pero no la vuelve ejecutable con juicio: para eso el rol necesita su segunda mitad, el contexto gobernado. Primero el puesto, después la asignación, después el contrato, después el contexto. Recién entonces se habla de autonomía. Nadie serio entrega las llaves el primer día.
Preguntas frecuentes
El AI Role Contract, el contrato de rol, es el documento operacional que define el puesto que ocupa un Empleado IA: para qué existe, qué resultados debe producir, con qué autoridad, dentro de qué límites y bajo la responsabilidad de qué humano. No es una pieza legal: es la combinación funcional de una buena descripción de puesto y un acuerdo explícito de operación. Su propósito es convertir capacidad tecnológica en responsabilidad administrable: sin contrato, la organización tiene un sistema con permisos, pero no un puesto gobernado por el que alguien responde.
El glosario del estándar (G-03) lo define con esta lista exacta: misión, responsabilidades, resultados, KPIs, autoridad, exclusiones, herramientas, accesos, nivel de servicio, escalamiento, criterios de suspensión, calendario de gobernanza y accountable owner, todo versionado. En la práctica destacan cuatro piezas: la tabla de autoridad con sus exclusiones explícitas (lo que no puede hacer vale tanto como lo que puede), los destinos de escalamiento para cada excepción, el kill switch con responsable y condición de uso, y el calendario de gobernanza que consolida todas las fechas de revisión con un único dueño del cronograma.
Es el humano que responde por el diseño y el desempeño del rol, y el estándar exige exactamente uno. Puede ser una persona con nombre o un cuerpo humano de gobierno, pero un comité solo cuenta si tiene presidente identificado, reglas de decisión declaradas y capacidad de actuar en una emergencia. «El área de finanzas» no responde por nada: las áreas no firman. El owner no es el supervisor: supervisar es trabajo y puede delegarse, incluso a otro recurso artificial, pero la accountability no se delega jamás. Y es primario, no exclusivo: las obligaciones de seguridad, datos y proveedor sobreviven intactas.
Con la cadencia que el propio contrato declare, y la cláusula HWF-61 le pone un tope: nunca mayor a doce meses. La decisión de cambiar el contrato es siempre humana. Además de la revisión periódica, el calendario de gobernanza agenda las revalidaciones tras cambios relevantes (productos, políticas, modelos, riesgos), los simulacros del kill switch y la re-justificación de la existencia del puesto. El versionado completa el ciclo: permite saber qué autoridad existía en un momento determinado y qué modificación produjo una mejora o un deterioro.
El contrato formaliza un puesto que ya fue diseñado y asignado: ese orden se explica en Work Resource Management. La segunda mitad del rol, el contexto gobernado, está en Contexto para IA empresarial.
¿Querés el método completo? Leé Empleado IA. Para consultoría ejecutiva en IA o conferencias y talleres.
Profundizar
¿Querés llevar tu equipo al siguiente cinturón?
Reservá una llamada de descubrimiento o explorá el libro completo.