Modelo operativo AI-native: las nueve preguntas que tu organización todavía no respondió
Adoptar IA no es comprar licencias. Es responder quién hace qué trabajo, qué decide un humano, qué ejecuta un agente y cómo se registra cada decisión. Sin esas respuestas, la organización tiene herramientas pero no modelo operativo.
La mayoría de las organizaciones que dicen estar adoptando inteligencia artificial han hecho exactamente una cosa: comprar acceso a herramientas. Licencias de copilotos, suscripciones a plataformas de modelos, un par de pilotos en áreas dispuestas a experimentar. Eso no es un modelo operativo. Es aprovisionamiento.
La diferencia importa porque el modelo operativo es lo que determina si el trabajo efectivamente cambia. Un modelo operativo responde una pregunta aparentemente simple: cómo se hace el trabajo aquí, quién lo hace, con qué autoridad y bajo qué controles. Durante décadas esa pregunta tuvo una respuesta implícita y estable: lo hacen personas, organizadas en áreas, con jefes que aprueban. La IA rompe esa estabilidad porque introduce un actor nuevo que ejecuta trabajo pero no es una persona, no tiene puesto, no está en el organigrama y no responde ante nadie salvo que alguien lo diseñe explícitamente.
En 2026 ya no basta con preguntar cómo coordinamos equipos. Hay nueve preguntas que una organización tiene que responder por escrito, y la mayoría no ha respondido ninguna.
Las nueve preguntas
1. Qué trabajo realiza una persona. No qué trabajo podría realizar, sino cuál queda deliberadamente en manos humanas y por qué. Las razones válidas son pocas y concretas: juicio contextual que no está en ningún dato, responsabilidad legal indelegable, relación con un cliente donde la presencia importa, decisiones cuyo error es irreversible. Todo lo demás es candidato a revisión.
2. Qué trabajo puede ejecutar un agente. Esta es la contracara, y no se responde con una lista de casos de uso sino con criterios: tareas con un resultado verificable, con contexto disponible, con costo de error acotado y con posibilidad de deshacer.
3. Qué decisiones requieren aprobación. Y de quién. Un umbral de monto, un tipo de cliente, una categoría de cambio. Si la respuesta es “depende”, el sistema no tiene control: tiene costumbre.
4. Qué acciones deben ser reversibles. Esta pregunta es la más subestimada. La reversibilidad es lo que convierte un error en un incidente menor en vez de en una crisis. Diseñar para que las acciones de un agente se puedan deshacer es más barato que diseñar para que nunca se equivoque.
5. Qué contexto puede consultar el agente. Un agente sin acceso a datos internos produce respuestas genéricas. Un agente con acceso indiscriminado produce fugas. Entre esos dos extremos hay una decisión de arquitectura que alguien tiene que tomar y documentar.
6. Qué sistemas puede modificar. Leer y escribir son permisos radicalmente distintos. La mayoría de las organizaciones que despliegan agentes no han hecho esa separación con precisión, porque heredaron credenciales de servicio con permisos amplios que nadie revisó.
7. Cómo se evalúa la calidad de sus resultados. Sin un conjunto de casos de evaluación y un criterio de aprobación, “funciona bien” es una impresión. Y las impresiones sobre sistemas probabilísticos son notoriamente poco confiables.
8. Cómo se registra quién o qué tomó cada decisión. Cuando un cliente reclama, cuando un auditor pregunta, cuando algo sale mal: alguien tiene que poder reconstruir qué pasó. Si la traza no existe, la organización no puede defenderse ni aprender.
9. Cómo se controla costo, seguridad y autonomía. Un agente que consume presupuesto sin límite es un riesgo financiero. Uno que opera sin límites de acción es un riesgo operativo. Los límites tienen que ser explícitos y aplicados por el sistema, no por la buena voluntad de quien lo configuró.
Por qué las herramientas solas no producen el beneficio
El programa de investigación DORA identifica siete capacidades que amplifican el valor de la inteligencia artificial en una organización: una posición organizacional clara sobre su uso, ecosistemas de datos saludables, datos internos accesibles para IA, prácticas fuertes de control de versiones, trabajo en lotes pequeños, foco en el usuario y una plataforma interna de calidad.
Lo relevante de esa lista no es cada elemento por separado. Es lo que implica en conjunto: ninguna de esas siete capacidades es una herramienta de IA. Son propiedades del sistema de trabajo que ya existe. La conclusión práctica es incómoda pero útil: la IA amplifica tanto las fortalezas como las disfunciones del sistema existente. Si tu proceso de despliegue es lento y frágil, la IA te va a permitir generar código defectuoso más rápido. Si tus datos están desordenados, la IA va a producir respuestas seguras de sí mismas construidas sobre datos malos.
Esto explica un patrón que se repite: organizaciones que invierten fuerte en herramientas y reportan mejoras locales de productividad —“escribo el borrador en la mitad del tiempo”— sin ninguna mejora medible en resultados de negocio. La mejora local es real. Simplemente se disuelve en el resto del sistema, en las esperas, en las aprobaciones, en el retrabajo que nadie mide.
El cambio de fondo en el trabajo del que produce
Hay un desplazamiento más profundo que el de la productividad. El trabajo de quien construye pasa progresivamente de escribir directamente cada artefacto a diseñar entornos, especificar intención y construir ciclos de retroalimentación que permitan a los agentes operar con confiabilidad.
Dicho de otro modo: el recurso escaso deja de ser la capacidad de producir y pasa a ser la atención humana. Producir borradores, código, análisis o propuestas se abarata. Revisar, decidir, corregir y responsabilizarse no. Si una organización multiplica por cinco su capacidad de generar artefactos sin cambiar su capacidad de revisarlos, no aumentó su rendimiento: movió el cuello de botella y lo hizo más caro.
Ese es el argumento central para tratar la adopción de IA como diseño organizacional y no como compra de tecnología. Las nueve preguntas de arriba no son un ejercicio de gobernanza defensiva. Son la forma de proteger el recurso que efectivamente se volvió escaso.
Cómo empezar sin construir un comité
La reacción típica de una organización mediana frente a esta lista es crear un comité de IA que produzca una política de veinte páginas que nadie lee. Hay un camino más corto.
Toma un solo proceso real, acotado y con dueño identificable. Puede ser la respuesta a solicitudes de cotización, la clasificación de tickets de soporte o la preparación de informes recurrentes. Sobre ese proceso, responde las nueve preguntas por escrito. Una página. No más.
El resultado no será una política corporativa. Será algo más útil: la primera evidencia de que tu organización puede articular cómo trabaja con agentes, en un caso donde las consecuencias son manejables. A partir de ahí, el mismo formato se replica. Y cada replicación es más rápida que la anterior, porque las decisiones de fondo —qué se registra, qué requiere aprobación, quién es dueño de la evaluación— ya se tomaron una vez.
Lo que no funciona es el orden inverso: desplegar primero, gobernar después. Para cuando la organización descubre que necesita saber quién tomó una decisión, la decisión ya se tomó y la traza no existe.
Quién responde estas preguntas
Hay una objeción práctica que aparece de inmediato: ¿de quién es este trabajo? Las nueve preguntas cruzan tecnología, operaciones, legal, riesgo y el área dueña del proceso. Y lo que cruza a todos suele no ser de nadie.
La respuesta que funciona no es crear una función nueva. Es asignar cada pregunta a quien ya tiene la autoridad correspondiente.
Las preguntas uno y dos —qué hace una persona, qué puede hacer un agente— pertenecen a quien es dueño del proceso. Nadie más está en condiciones de decidir qué trabajo se delega, porque nadie más responde por su resultado.
Las preguntas tres y nueve —qué requiere aprobación, cómo se controlan costo y autonomía— pertenecen a quien tiene autoridad presupuestaria y de riesgo sobre esa área. Son decisiones de exposición, no técnicas.
Las preguntas cuatro a siete —reversibilidad, contexto accesible, sistemas modificables, evaluación de calidad— pertenecen a quien construye y opera. Son decisiones de diseño con consecuencias de negocio, y necesitan que las dos categorías anteriores estén respondidas primero para tomarse bien.
La pregunta ocho —cómo se registra quién o qué decidió— es la única que conviene centralizar. El formato de la traza debe ser común a toda la organización, porque su valor está en poder reconstruir un proceso que cruza áreas. Si cada área registra a su manera, la reconstrucción es un ejercicio de reconciliación.
Ese reparto tiene una consecuencia útil: convierte una discusión abstracta sobre gobierno de IA en cuatro conversaciones concretas con interlocutores identificables. Y hace evidente el punto que más se resiste: la decisión sobre qué trabajo delega una organización a un agente no es una decisión de tecnología. Es una decisión de quien responde por el resultado de ese trabajo.
Cuando esa asignación no se hace, el vacío se llena solo, y casi siempre de la misma forma: decide quien implementa, porque es quien está frente al teclado. No por ambición, sino porque alguien tenía que decidir para poder avanzar. El problema aparece después, cuando la decisión tiene consecuencias y la persona que la tomó no tenía mandato para asumirlas.
La pregunta de cierre
Si alguien de tu directorio preguntara mañana “¿qué trabajo en esta empresa lo hace hoy un agente y bajo qué autoridad?”, ¿existe un documento que responda eso? No una intuición, no una lista de herramientas contratadas: un documento.
Si la respuesta es no, tu organización tiene adopción de IA sin modelo operativo. Es una posición común y por ahora tolerable. Deja de serlo en el momento exacto en que algo sale mal.