Agentes en la empresa: contexto, encargo y permisos para delegar con control

El contexto es un activo mantenido, no una carpeta que crece

context as code (contexto como código): arquitectura y convenciones actualizadas, una capa que agregue datos consultables y metadatos para cargar solo lo necesario. En organizaciones grandes, matiza The AI Daily Brief, es más realista una malla de fuentes que los agentes recorren señalando discrepancias para que las resuelvan personas.

Propuesta: cada documento legible por un agente lleva en cabecera dueño nombrado, versión, fecha de última revisión y disparador de cambio —al cambiar el proceso, más una revisión periódica fijada—. Sin dueño, no entra: se archiva o se adopta.

Por escrito, los conflictos conocidos: qué fuente prevalece y a quién se escala la contradicción. Y acceso mínimo: qué fuentes consulta el agente según el tipo de tarea, no el repositorio entero.

La ficha de encargo: qué resultado, quién lo acepta y qué no se delega

Las personas definen la intención y los criterios de aceptación; el análisis añade propiedad: la pregunta no es si la IA puede hacer la tarea, sino quién responde del resultado.

Propuesta: ficha de encargo de una página antes de automatizar, con el resultado esperado en una frase; criterio de aceptación escrito antes de ejecutar y verificable con un sí o un no; quién firma, quién revisa antes de que salga de la organización y quién mantiene el montaje cuando cambie el modelo o la fuente. Los papeles se reparten, no se concentran.

Apartado de no delegado, taxativo: efectos jurídicos, comunicación externa sin revisión, excepciones a políticas, datos maestros, pagos. Si no se puede escribir el criterio, la tarea no está lista.

Permisos mínimos, aplicados donde están los datos

Las barreras van antes que las funcionalidades: Lieberman propone que los agentes hereden los permisos de quien pregunta y que esos permisos se apliquen en la capa de datos.

Tres ejes: identidad (cuenta propia del agente, trazable, no la de un empleado), rol y operación (qué acción sobre qué recurso). Lectura y escritura separadas: por defecto solo lectura; escritura hacia destinos nombrados. Con datos personales o confidenciales, acceso solo si la tarea lo exige, mínimo de campos y retención definida de registros, entradas y salidas, acordada con legal y cumplimiento.

El contenido recibido —correos, adjuntos, tickets, páginas— es dato, nunca instrucción, y no amplía permisos: respuesta operativa al prompt injection (inyección de instrucciones); reduce la exposición, no la elimina. Antes de tocar sistemas reales, pruebas en sandbox (entorno aislado), con datos ficticios y credenciales sin acceso a producción.

Ejemplo hipotético: conciliación de facturas de proveedor, peldaño a peldaño

Ejemplo hipotético, no ejecutado, construido para ilustrar los controles anteriores. Entrada: tres documentos por operación —factura recibida, pedido de compra y registro de recepción—. Alcance: comparar importes, cantidades, referencias y condiciones, y dejar la operación clasificada. Fuera de alcance, sin excepciones: ordenar o modificar pagos, alterar datos bancarios, dar de alta proveedores, modificar pedidos. Salida: lista diaria con tres estados —conciliada, discrepancia con causa señalada, excepción que requiere persona—. La evidencia de aceptación es la firma del responsable de cuentas a pagar sobre el resultado del lote, detallando qué línea aceptó, cuál corrigió y cuál devolvió; es un acto posterior y distinto de la autorización previa a ejecutar.

Los cuatro peldaños: observar, sugerir, actuar con autorización previa y actuar dentro de una frontera definida. En el primero el agente lee y clasifica en paralelo al trabajo humano durante un periodo acordado; nadie usa su salida, que se contrasta con la de las personas sobre la misma muestra. La prueba de paso no es un porcentaje genérico de acierto: debe cubrir tres casos. Sospecha de duplicado: la coincidencia de importe y fecha con número distinto no demuestra duplicidad, es un indicio que obliga a marcar para revisión, nunca a conciliar ni a descartar. Proveedor no reconocido en el maestro: excepción inmediata, prohibido inferir el correcto. Dato faltante —recepción no registrada, importe ilegible en un escaneo—: excepción, nunca estimación.

En el segundo peldaño el agente propone y una persona confirma línea a línea. En el tercero, el responsable autoriza antes de ejecutar un lote identificado, con importe total y número de líneas a la vista; esa autorización vale solo para ese lote. Para el cuarto, recomendación editorial: habilitar actuación sin autorización previa únicamente en acciones reversibles y de bajo impacto —marcar conciliada una coincidencia exacta three-way match (cotejo a tres bandas) por debajo de un umbral fijado por dirección financiera, con muestreo posterior—; discrepancias, excepciones, datos bancarios y toda la cadena de pago siguen requiriendo persona. La propiedad no sube la escalera: el responsable de cuentas a pagar responde del cierre; el técnico, del montaje.

Coste por tarea realmente aceptada: cómo calcularlo sin engañarse

Lieberman propone como métrica de ingeniería el coste por pull request aceptada (solicitud de incorporación de código admitida en el repositorio), reducible con mayor eficiencia de tokens (unidades de texto que procesa el modelo). Para The AI Daily Brief, las métricas de la entrega agéntica apenas empiezan a definirse e incluirán, a su juicio, alguna noción de completitud y de coste por completitud. Extenderla a tareas no técnicas es una generalización editorial de esta guía.

Fórmula: sumar todo el coste del periodo —todos los intentos, incluidos los fallidos; los reintentos; las llamadas a herramientas y sistemas externos; la revisión humana; el retrabajo; el mantenimiento del montaje— y dividirlo entre las tareas únicas aceptadas en ese mismo periodo. Los intentos fallidos nunca salen del numerador; una tarea reintentada cinco veces cuenta una vez en el denominador. Con cero aceptadas no hay denominador válido: la métrica no existe y procede parar y revisar el diseño.

El coste no decide solo: se registran calidad contra el criterio de aceptación escrito, latencia hasta resultado utilizable y tasa de error, separando el error detectado en revisión del que salió de la organización. La comparación con el trabajo manual exige la misma muestra de operaciones, el mismo revisor y los mismos criterios de aceptación. Esta guía no aporta cifras: cada organización mide las suyas.

Cuándo parar, cómo revertir y cómo ampliar el despliegue

Límites duros declarados antes de arrancar: intentos máximos por tarea y topes de gasto por tarea y por periodo, además de topes por periodo de operaciones y volumen; alcanzado un tope, el agente se detiene y avisa. También se detiene y avisa ante error crítico, acceso inesperado o calidad insuficiente. Ante una petición incierta —no consta si la acción llegó a completarse—, leer el estado del sistema de destino antes de reintentar: el reintento ciego puede duplicar, y un duplicado financiero es un incidente.

Lieberman plantea la trazabilidad como señal de entrenamiento: rastrear cada salida hasta su instrucción, modelo, datos y aprobador. Recomendación editorial sobre su límite: registrar lo justo para reconstruir la decisión —identificadores, versiones, fuentes, aprobador, resultado—, no copias íntegras con datos personales o bancarios. El responsable designado debe poder revocar el acceso y cortar la cola pendiente sin cambio técnico, capacidad probada de antemano.

Reversión según el tipo de acción. Las reversibles —clasificación, etiqueta, borrador— se deshacen en el propio sistema, documentando quién. Las irreversibles —correo enviado, asiento contabilizado, fichero remitido a un tercero— exigen compensación humana con plazo y responsable asignados en el incidente. Por eso lo no delegado debe concentrar lo irreversible. Y el procedimiento manual debe seguir siendo practicable: sin él no hay contingencia, hay dependencia.

El rollout (despliegue progresivo) avanza por criterio: un proveedor o categoría de gasto, luego un porcentaje del volumen, subiendo solo si las métricas se sostienen. Lieberman sitúa las evaluaciones como infraestructura permanente ante modelos nuevos. Norma interna sugerida: cambiar de modelo, versión, contexto o permisos obliga a repetir las pruebas de paso —duplicado, proveedor desconocido, dato faltante— antes de conservar el nivel de autonomía alcanzado.