En una empresa, gran parte del criterio vive disperso: en políticas formales, SOPs, historiales de clientes, conversaciones, excepciones conocidas y decisiones que alguien recuerda porque estuvo presente. Cuando un colaborador nuevo aprende, no recibe solo información: absorbe patrones sobre lo que la organización valora y cómo actúa cuando las reglas generales no alcanzan.
Una persona con experiencia completa los vacíos con intuición. Un Empleado IA no: solo puede trabajar con el contexto disponible, las herramientas autorizadas y las reglas que la organización logró explicitar. Antes de evaluar si posee criterio, hay que preguntarse si la empresa convirtió su criterio en algo que pueda enseñarse, consultarse y gobernarse. A veces el modelo falla. Otras veces el fracaso revela algo más incómodo: ni siquiera los humanos podían explicar cómo se tomaba la decisión correcta.
A esa disciplina el libro Empleado IA la llama Context Provisioning: el aprovisionamiento del contexto que produce criterio. El contrato de rol define la responsabilidad; el contexto la vuelve ejecutable con juicio.
Debe saber, puede consultar, no debe acceder
El libro divide el contexto en tres grupos. Debe saber: aquello sin lo cual el rol no puede ejecutarse (misión, productos relevantes, políticas, KPIs, límites, rutas de escalamiento). Puede consultar: información necesaria solo en ciertos casos (documentación ampliada, antecedentes, casos históricos, catálogos). No debe acceder: los datos, sistemas y decisiones que quedan fuera de su necesidad operacional.
La división parece obvia hasta que intentás escribirla para un rol concreto. ¿El rol de cobranza necesita el historial completo de disputas, o solo la marca de que la cuenta está en disputa? ¿Necesita los márgenes del producto para redactar un recordatorio de pago? Cada respuesta es una decisión de diseño. Y las decisiones de diseño se registran.
Retener contexto también es diseñar
La tercera categoría tiene dos fundamentos, y casi todo el mundo solo ve el primero: proteger la información del recurso. Es el mínimo privilegio de toda la vida, porque el contexto es capacidad pero también superficie de riesgo.
El segundo es menos intuitivo e igual de importante: proteger la decisión de la información. Un recurso que ve todas las disputas anteriores de un cliente se ancla en ellas y trata al cliente de hoy como el expediente de ayer. Uno que recibe todo lo «relevante» ahoga la señal en lo meramente relacionado. Más contexto no siempre produce mejor criterio; a veces produce un criterio contaminado con más elegancia.
Retener contexto puede ser legítimo en ambas direcciones, pero registrado: qué se retiene, por cuál fundamento, decidido por quién. La cláusula HWF-35 exige que toda restricción quede en el contrato como un registro de frontera de contexto, versionado y auditable. La retención sin registro es otra cosa: la excusa «el sistema no tenía ese contexto» esperando su turno.
La responsabilidad por una decisión degradada por contexto retenido recae en quien lo retuvo.
El contexto tiene dueño y fecha
El contexto necesita dueño, fecha y mecanismo de actualización. Una política obsoleta puede producir respuestas consistentes y equivocadas: el peor tipo de error, porque la consistencia disfraza la equivocación de confiabilidad. Un caso histórico puede ayudar a interpretar una excepción, pero no debería convertirse automáticamente en una regla. Por eso conviene distinguir hechos, criterios y ejemplos, para que el recurso no trate una anécdota como mandato.
La disciplina tiene un dividendo escondido: documenta el conocimiento tácito que dependía de una persona. Los humanos incorporados después aprenden mejor, los managers descubren contradicciones entre políticas que coexistían sin conocerse, las decisiones se vuelven auditables. Contexto es capacidad: un rol no puede decidir de acuerdo con una organización que nunca logró explicarse.
La memoria también es un sistema de datos
El rol diseñado acumula algo desde su primer día de operación: memoria. Promesas de pago registradas, patrones de respuesta, excepciones resueltas, correcciones recibidas. La memoria convierte cien ejecuciones en experiencia. Y es la superficie de datos más subestimada de la implementación: recordar mejora el desempeño y crea exposición en el mismo movimiento.
Y ni siquiera es la superficie completa: el estándar obliga a mirar cinco sistemas de datos, no uno. Las entradas: los prompts cargan confesiones, como el cliente que explica que no ha pagado porque está enfermo, o divorciándose, o demandado. Las salidas: cada mensaje enviado es una decisión registrada. Los resultados de herramientas: cada consulta al sistema contable trae datos de cuentas. La memoria propiamente dicha. Y la categoría que casi nadie ve venir: las inferencias derivadas.
Cuando el rol de cobros concluye que «este cliente probablemente está en apuros financieros», acaba de fabricar un dato sobre una persona que nunca lo entregó. Ese dato se gobierna como si se hubiera recolectado, y con frecuencia es más sensible que todo lo que sí se recolectó.
Los cinco necesitan lo mismo: finalidad declarada y base legal, minimización (recolectar lo que el rol necesita, no lo que la integración permite), controles de calidad y actualidad, manejo especial de datos sensibles, reglas para transferencias y para cualquier uso por parte del proveedor, aislamiento por empresa y eliminación verificable.
Proveedor, borrado y vigilancia
Dos requisitos merecen desarrollo porque las implementaciones reales los omiten. El primero es la regla del proveedor. Los datos pueden salir de tu organización por el canal más silencioso que existe: el pipeline de entrenamiento del proveedor del modelo, sin dejar rastro en tus sistemas. La regla tiene que ser contractual, no supuesta. Preguntale a tu proveedor por escrito si tus datos entrenan sus modelos; si la respuesta es un enlace a términos que pueden cambiar sin avisarte, ya tenés tu respuesta.
El segundo es la eliminación verificable: borrar y poder demostrar que se borró son capacidades distintas, y solo la segunda cuenta. Si un cliente te pidiera mañana borrar todo lo suyo, ¿podrías hacerlo, y podrías demostrarlo? Una eliminación que no puede demostrarse es retención con pasos extra.
Queda una vuelta de tuerca que el estándar se aplicó a sí mismo. Todo lo que exige el gobierno híbrido engorda un archivo donde aparecen personas: qué dijo el cliente, qué aprobó el analista, quién tardó en intervenir. Su propósito es la reconstrucción y la accountability; usarlo para puntuar empleados o perfilar clientes es un propósito nuevo que exige su propia justificación. Una organización que convierte su aparato de seguridad en un aparato de vigilancia envenena el incentivo de registrar honestamente, y descubrirá que la gente aprende a operar fuera del registro. Por eso auditar no es lo mismo que registrar, y los logs se gobiernan con la misma severidad que la operación que auditan.
Del rol diseñado al rol operativo
Un contrato con contexto todavía no trabaja. Convertirlo en operación exige unir contexto, herramientas, credenciales, canales y relaciones, y responder preguntas concretas. ¿Puede enviar una comunicación directamente, o solo preparar un borrador? ¿Puede cambiar un estado financiero, o solo recomendarlo? ¿Qué ocurre si el sistema de origen no está disponible? ¿Quién recibe una alerta, y por qué canal? ¿Cómo evitamos que una rutina se ejecute dos veces? ¿Qué canal representa la versión oficial de una decisión?
Cada respuesta reduce ambigüedad y convierte una integración técnica en una relación administrable. Queda la verificación 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 y conservar, por error, una credencial que se lo permite. La distancia entre el contrato y la configuración es exactamente el espacio donde viven los incidentes.
Al final queda un rol diseñado y habilitado, pero todavía no un ocupante confiable. Concederle autoridad completa el primer día sería tan irresponsable como dar control total a una persona antes de observar su trabajo. La capacidad se demuestra antes de que la autoridad se conceda.
Preguntas frecuentes
Context Provisioning es el aprovisionamiento del contexto que produce criterio: la disciplina de entregar a un Empleado IA una versión gobernada del conocimiento disperso de la empresa (políticas, SOPs, historiales, excepciones) para que ejecute su rol con juicio. Divide el contexto en tres grupos: debe saber, puede consultar y no debe acceder. Complementa al contrato de rol: el contrato define la responsabilidad, el contexto la vuelve ejecutable. Cada concesión y cada retención es una decisión de diseño registrada, con dueño, fecha y mecanismo de actualización.
No. Más contexto no siempre produce mejor criterio; a veces produce un criterio contaminado con más elegancia. Un recurso que ve todas las disputas anteriores de un cliente se ancla en ellas y trata al cliente de hoy como el expediente de ayer. Uno que recibe todo lo «relevante» ahoga la señal en lo meramente relacionado. Retener contexto puede ser una decisión de diseño legítima: por seguridad (mínimo privilegio) o para proteger la decisión de la información. La condición es registrar toda retención como frontera de contexto, porque la responsabilidad por una decisión degradada por contexto retenido recae en quien lo retuvo.
Cinco, según la cláusula HWF-42: las entradas (los prompts cargan confesiones de clientes), las salidas (cada mensaje es una decisión registrada), los resultados de herramientas (cada consulta trae datos), la memoria acumulada y las inferencias derivadas. Cada uno exige finalidad declarada y base legal, minimización, controles de calidad, manejo especial de datos sensibles, reglas para transferencias y para el uso por parte del proveedor (el entrenamiento de modelos incluido), aislamiento por empresa y eliminación verificable. Los registros de auditoría se gobiernan con la misma severidad que la operación que auditan: integridad protegida, acceso controlado, finalidad acotada.
Es un dato que el sistema fabrica sobre una persona que nunca lo entregó. Cuando un rol de cobranza concluye que «este cliente probablemente está en apuros financieros», acaba de crear información nueva a partir de señales dispersas. El estándar exige gobernar ese dato como si se hubiera recolectado, porque con frecuencia es más sensible que todo lo que sí se recolectó. Es la categoría que casi nadie ve venir, precisamente porque no aparece en ningún formulario ni integración: nace dentro del propio sistema, y sin gobierno explícito queda guardada sin finalidad declarada ni base legal.
Con el rol diseñado, contratado y aprovisionado, la autonomía todavía se gana con evidencia: el primer paso es el shadow mode, trabajar antes de poseer el trabajo.
¿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.