Por qué este blog ya no puede llamarse transformación digital

Una empresa del sector industrial automatizó su proceso de compras con un agente autónomo. Le dio un límite de presupuesto y la autoridad para aprobar pedidos por debajo de ese límite. A los seis meses, el agente había aprobado 347 transacciones. La auditoría interna descubrió que 89 de ellas no tenían una justificación legible por humanos, aunque estuvieran técnicamente dentro del presupuesto. El equipo legal no podía determinar si eran errores, fraude, o si el modelo estaba haciendo algo que nadie había pensado en preguntar.

No fue un fallo de ciberseguridad. No fue un bug. Fue una delegación operativa sin instrumentación para responder a la pregunta más básica: ¿por qué el sistema hizo esto?


El problema real

Cuando hablamos de «transformación digital», la mayoría de las organizaciones se refiere a mover papel a pantallas, automatizar tareas repetitivas o acelerar flujos de trabajo. Ninguno de esos términos describe lo que ocurre cuando entregas a un sistema autónomo la autoridad para actuar en nombre de la organización.

Eso es un problema distinto. No es de digitalización. Es de delegación.

La diferencia importa porque las soluciones también son distintas. La transformación digital se resuelve con software tradicional: bases de datos, APIs, integraciones, RPA. La delegación operativa requiere responder preguntas que ese software no sabe responder:

  • ¿Quién autorizó esta acción?
  • ¿Con qué información la tomó?
  • ¿Puede la organización reconstruir lo que ocurrió?
  • ¿Qué pasa cuando falla?
  • ¿Quién es responsable si la decisión fue incorrecta?

Las cinco preguntas no son nuevas. Llevan décadas formulándose en otros campos — auditoría financiera, control aéreo, sistemas médicos. Lo que es nuevo es que ahora las responde (o debería responderlas) un sistema que nadie diseñó específicamente para responderlas.


Lo que parece una solución pero no lo es

Hay tres patrones que las organizaciones confunden con «haber resuelto la gobernanza de la IA» cuando en realidad solo han cubierto la superficie.

1. Automatización de procesos (RPA)

RPA ejecuta reglas fijas contra datos estructurados. Es determinista, es rápido, es barato. No delega juicio: delega mecánica. Un RPA no aprueba una compra porque crea que es razonable; la aprueba porque la factura encaja con un patrón predefinido.

Esto está bien para lo que está bien. Pero cuando una organización tiene 89 transacciones sin justificación legible, no es un problema de RPA. Es un problema de algo que tomó decisiones que el RPA nunca tomaría.

2. Asistentes de IA

ChatGPT, Copilot, Claude y similares son sugerencias. Proponen. No deciden. Mientras el flujo operativo requiera que un humano apruebe cada acción, el «asistente» sigue siendo una herramienta, no un delegado.

El problema aparece cuando la organización acelera el flujo y el humano deja de aprobar cada acción. En ese momento, lo que era sugerencia se convierte, en la práctica, en decisión. Pero el sistema sigue siendo el mismo. No se ha rediseñado para actuar como delegado, solo se ha acelerado.

3. «Human-in-the-loop»

Esta es la trampa más común. La mayoría de los vendors prometen «human-in-the-loop» como si eso resolviera la delegación. Pero «human-in-the-loop» rara vez significa «human que puede impedir la acción»; significa «human que la revisa después». La acción ya ocurrió.

Cuando la IA envía el email, cancela la reserva, ejecuta la compra o publica el contenido, el humano no está en el loop: está después del loop. Para entonces, el efecto ya está en el mundo.

Una gobernanza que solo mira hacia atrás no es gobernanza; es peritaje. Sirve para entender qué pasó, no para asegurar que lo que pase sea lo correcto.


Qué pregunta hay que responder (y este blog no responde)

A partir de ahora, cada pieza de este blog va a orbitar alrededor de una sola pregunta:

Cuando un sistema autónomo actúa en nombre de tu organización, ¿puedes responder a las cinco preguntas que importan?

Esas cinco preguntas son las que el canon formal de la investigación llama «obligaciones de prueba» (proof obligations). En el paper fundacional del corpus — Vertical AI Manifesto — están formuladas como principios. En el Vertical AI Governance Stack v1.0 están operacionalizadas como capas (L1 a L6). En la Implementation Conformance Checklist v1.0 están convertidas en preguntas auditables.

Este blog no responde a esas preguntas. Lo que hace es plantearlas en contextos reconocibles para que, si trabajas en una organización donde la IA ya está tomando decisiones operativas, sepas qué preguntar antes de que sea tarde.

Y si después de leer una pieza de aquí quieres la versión formal, con la teoría, las pruebas experimentales y las referencias, el canon está público y enlazado al final de cada artículo.


Lo que sí vas a encontrar en este blog

  • Casos de auditoría reales. No casos anonimizados para parecer prudentes: casos reales publicados, como las auditorías aplicadas al OpenAI Swarm y al OpenAI Agents SDK, donde se documenta exactamente qué gap se encontró entre lo que el framework promete y lo que el framework hace.
  • El hallazgo empírico del punto ciego del oráculo. Cuando los tests automatizados mienten, y por qué las organizaciones no lo descubren hasta producción.
  • El principio de soberanía semántica. Por qué el conocimiento operativo de tu organización no debería vivir dentro del modelo, y qué pasa cuando lo hace.
  • Cómo auditar L1-L6 en una organización real. La checklist traducida a decisiones que un director de operaciones puede tomar sin leer el paper entero.

Lo que no vas a encontrar aquí:

  • Visión genérica sobre «el futuro de la IA».
  • Frases como «la IA va a cambiar el mundo» sin contexto operativo.
  • Métricas inventadas sobre «ROI de la IA» o «ahorro de costes» sin anclaje en un experimento concreto.
  • Recomendaciones motivacionales que no sobrevivan a una pregunta técnica directa.

Cada pieza termina con un enlace al paper canónico que respalda lo que se ha dicho. El canon está en research.latinflash.com y es la única fuente normativa de este blog. Si en algún momento este artículo y el canon divergen, gana el canon.


Si quieres ir a la versión formal

El artículo fundacional de esta línea de trabajo es Vertical AI Manifesto: Semantic Sovereignty and Executable Governance. Lo encuentras en:

research.latinflash.com/papers/vertical-ai-manifesto/

Ahí encontrarás la tesis de soberanía semántica y gobernanza ejecutable que sostiene todo lo que se publique en este blog. Si solo vas a leer un paper del corpus, lee ese. Después, si quieres profundizar, el orden natural es:

  1. Vertical AI Governance Stack v1.0 — la arquitectura de referencia.
  2. Implementation Conformance Checklist v1.0 — cómo auditar en la práctica.
  3. The Oracle Blind Spot — qué puede salir mal en la verificación.
  4. Applied Audit 01 — OpenAI Swarm y Applied Audit 02 — OpenAI Agents SDK — auditorías reales.

¿Trabajas en una organización donde la IA ya está tomando decisiones operativas y necesitas contrastar tu caso antes de que aparezca un incidente? El punto de partida más útil suele ser la auditoría de L1-L6. Si quieres explorar ese camino, el siguiente post es sobre cómo hacerlo en una semana, no en un trimestre.

— Manuel Enrique Morales Santiago

Deja un comentario