El shadow IT no escala dentro de una empresa regulada

Cualquiera de tu equipo puede hoy construir una automatización útil en una tarde. Un script lee una bandeja de entrada, llama a un modelo, deja un resumen en un ticket. La demo es preciosa. Corre en un portátil. Durante un tiempo, incluso ayuda.

Solo que hay un abismo entre esa automatización y un agente que la organización opera de verdad, y el abismo no va de la calidad del modelo. Va de todo lo que la demo nunca tuvo que gestionar: identidad, privilegio mínimo, drift, auditoría, y el simple hecho de que la cosa ahora actúa sobre datos que no generó.

La mayoría de los equipos lee mal esta distancia, como si fuera un problema de prompt. Asume que un prompt mejor, un modelo más grande o una cadena más ingeniosa convertirán el script de portátil en algo que la empresa pueda defender. No lo harán. La distancia entre una automatización de portátil y un agente en producción es de arquitectura, no de prompting. Las piezas que faltan son estructurales, y ninguna cantidad de ingeniería de prompts las hace aparecer.

Una regla determinista y un agente probabilístico son sistemas distintos

Mira la diferencia en concreto.

Una regla determinista de validación de facturas pasa o falla, y falla siempre igual. Puedes probarla una vez y confiar en la prueba. Toda tu gobernanza de TI descansa en ese supuesto: una build probada sigue probada, las entregas pasan control de cambios, y la misma entrada produce la misma salida.

Un agente que valida un expediente de crédito rompe los tres supuestos. Lee documentos que no ha visto nunca, razona sobre ellos de forma probabilística y puede llegar mañana a otra conclusión porque el modelo de debajo se actualizó de noche. Nada en tu proceso de control de cambios se diseñó para notar que el sistema cambió sin que tú entregaras nada.

Esto es lo primero que hay que admitir con honestidad. Una automatización de portátil puede ser genuinamente útil y completamente no responsabilizable al mismo tiempo. Esas dos propiedades no están en tensión en la máquina de alguien. Se vuelven irreconciliables en cuanto la cosa toca trabajo regulado.

Tres giros definen el abismo

El abismo no es un muro. Son tres, y cada uno es donde muere en silencio un piloto bienintencionado.

De código de confianza a entrada controlada por el adversario. El software tradicional procesa datos que tus sistemas produjeron. Un agente lee contenido que no escribió: un correo de cliente, un contrato escaneado, un PDF de un tercero. Ese contenido no es de confianza. Si un documento envenenado contiene texto que se lee como una instrucción, y el agente lo trata como tal, el documento acaba de secuestrar un sistema con acceso a tus plataformas centrales. Es la prompt injection indirecta, y la configuración por sí sola no la detiene. Al script del portátil nunca le tuvo que importar. El agente en producción no se puede permitir que no le importe.

De entregas estáticas a drift continuo. Tu proceso de entregas asume que el cambio es un evento que se programa. Una actualización de modelo es un cambio que no programaste y no entregaste. El comportamiento del agente se mueve bajo tus pies. Un sistema que se portaba bien en la demo del mes pasado puede degradarse en silencio este mes, y sin monitorización de drift te enteras por un cliente, no por un panel.

De la stack de un proveedor a la stack de tu regulador. En un portátil, quien desarrolla elige el modelo que le venga bien. En una empresa regulada, qué modelos puedes usar, y dónde corren, lo fija tu régimen regulatorio y tu propia homologación de seguridad. La comodidad no es una entrada admisible en esa decisión.

Cada giro corresponde a una pieza de arquitectura que la demo nunca tuvo. La automatización pasó la demo precisamente porque ninguno de estos tres estaba en alcance. La versión empresarial no escala porque los tres lo están.

La identidad es donde el modelo del portátil se rompe primero

De los tres giros, la identidad es el que detiene proyectos en el comité de seguridad, así que conviene ser preciso.

La automatización de portátil corre bajo el token personal de quien la hizo, con acceso permanente a producción. Es eficiente y es también el hallazgo que acaba con el proyecto. Un token de desarrollador robado es una llave maestra. Nada en él está acotado, es de corta duración ni queda registrado con el detalle que exige un proceso regulado.

La postura de producción es la contraria. Cada agente corre bajo su propia identidad no humana, con credenciales de corta duración y privilegio mínimo y una allow-list de salida explícita. Al agente se le conceden unas pocas capacidades con nombre, read_dossier, request_document, post_decision_for_review, y nada más. Una credencial de agente robada no vale entonces casi nada, porque no hay secreto estático que robar y la identidad solo puede ejecutar el puñado de acciones para las que se acotó, hacia el puñado de destinos que tiene permitidos.

Fíjate en lo que esto cambia para quien tiene que aprobarlo. "El agente puede tocar nuestros sistemas" no es auditable ni aprobable. "El agente puede ejecutar estas siete acciones con nombre, cada una registrada" es un control que un comité puede firmar. Esa traducción, de una capacidad vaga a un conjunto de acciones nombradas y comprobables, es casi todo lo que significa en la práctica convertir el shadow IT en un activo de empresa.

Convertir una herramienta en un activo que la empresa puede defender

Nada de esto es un argumento contra que la gente construya automatizaciones. Esos experimentos son cómo salen a la luz las buenas ideas, y deberían seguir pasando. El argumento es contra fingir que un experimento es un sistema de producción porque funciona en una demo.

Convertir una automatización de portátil en algo que la organización opera significa darle tres cosas que nunca tuvo: una identidad, una frontera alrededor de lo que lee y un registro de lo que decidió y por qué. Añade monitorización de drift para que una actualización silenciosa de modelo no la degrade sin que nadie lo note. Añade una capa de política para que las decisiones con consecuencia se queden con una persona. No es burocracia encima de una herramienta que funciona. Es la diferencia entre una herramienta y un activo que la empresa puede defender ante un regulador.

Las organizaciones atrapadas en el cementerio de los pilotos casi siempre pasaron la demo y luego chocaron con uno de estos muros. Se proyecta que cerca del 40% de los proyectos de IA agéntica se cancelen antes de 2027 (Thoughtworks), y la mayor parte de ese fracaso es arquitectónico, no técnico. Escalaron el portátil, no la arquitectura, y no son lo mismo.

El replanteamiento que merece la pena llevar a tu próxima revisión de arquitectura es este. No "¿cómo hacemos nuestra automatización más precisa?", sino qué tiene que construir nuestra organización para que esto pueda actuar aquí con seguridad, bajo una identidad, sobre datos que no controlamos, con un registro que podamos inspeccionar. Responde a eso y has cruzado el abismo. Sáltatelo y te queda una demo muy buena que nunca saldrá del portátil.

Si quieres poner a prueba dónde se sitúa una de tus automatizaciones en ese abismo, reserva una reunión y tráenos la más difícil.