· Por Ricardo Torres Oliva
Lo que un Director debe saber sobre Implementación IA
Lo que un director tiene que poder preguntar antes de aprobar una iniciativa de inteligencia artificial, y las respuestas que descalifican.
Abstract
Aprobar una inversión en inteligencia artificial sin poder interrogarla convierte al directorio en firmante de lo que otros deciden, y desde 2026 esa firma tiene consecuencias fiduciarias. Dirigido a directores y comités que aprueban presupuesto de IA sin ejecutarlo, el texto reúne tres instrumentos de uso inmediato: siete exigencias que toda propuesta debe cumplir antes de firmarse, un cuestionario de trece preguntas al proveedor con la respuesta que descalifica en cada caso, y el tablero de cinco indicadores con que se comprueba, meses después, si lo implementado funciona. Cierra con lo que no conviene comprar y con siete acciones ejecutables en la próxima sesión. Ninguna requiere formación técnica; todas son verificables por un tercero.
Un directorio no implementa inteligencia artificial: aprueba, exige y verifica. Este documento entrega las tres herramientas de ese oficio — qué preguntar a un proveedor, qué exigir por escrito antes de firmar, y con qué evidencia comprobar después que lo implementado funciona. No enseña tecnología. Enseña a decidir sobre ella.
1. El problema
El 80% de los líderes de C-suite declara alta confianza en su estrategia de inteligencia artificial. El 35% pasa una evaluación foundational de alfabetización en IA [fuente: The Phoenix Doctrine v1.1]. La distancia entre esas dos cifras es el problema entero, y tiene nombre propio en la doctrina: disonancia cognitiva ejecutiva.
Esa distancia se paga en dinero. El 95% de los pilotos de IA generativa no entrega retorno medible, y la causa documentada no es inmadurez tecnológica: es que la organización que los implementa carece de la fluidez ejecutiva para traducir objetivos de negocio en arquitecturas viables [fuente: The Phoenix Doctrine v1.1]. A escala de mercado, esa brecha de retorno se estima en torno a 600 mil millones de dólares [fuente: AI Literacy A Multi-Dimensional Analysis of Governance, Revenue Systems, and Epistemic Rigor in the Agentic Era].
Hasta 2024 eso era un problema de eficiencia. Desde 2026 es un problema fiduciario. La doctrina legal que la literatura de gobierno corporativo llama Expertise Trap sostiene que un director que no comprende la lógica fundamental de las herramientas algorítmicas que moldean sus decisiones puede responder personalmente por falta de diligencia. La contrapartida es la Business Judgment Rule 2.0: la protección legal se conserva solo para quien puede demostrar interrogación crítica de la herramienta, no aceptación de su output [fuente: AI Literacy A Multi-Dimensional Analysis of Governance, Revenue Systems, and Epistemic Rigor in the Agentic Era].
La postura de este documento es simple. Comprar inteligencia artificial sin capacidad de interrogar lo que se compró no es delegación. Es abdicación con factura.
2. Por qué los enfoques habituales fallan
Contratar talento técnico y delegar. El 38% de las empresas ha nombrado un Chief AI Officer, y su efectividad queda socavada de forma sistemática por líneas de reporte fragmentadas [fuente: AI Literacy A Multi-Dimensional Analysis of Governance, Revenue Systems, and Epistemic Rigor in the Agentic Era]. La escasez real nunca fue de ingenieros. Es de ejecutivos que sepan qué pedirles, cómo evaluarlos y cómo integrar lo que producen en decisiones de negocio [fuente: The Phoenix Doctrine v1.1]. Una organización con buenos ingenieros y mal liderazgo en IA produce pilotos brillantes que no escalan.
Comprar una transformación de tres años. Es el medio frágil: presupuesto masivo, horizonte largo, retorno lineal prometido. En un campo que cambia dramáticamente cada seis meses, ese proyecto llega obsoleto a la mitad del camino [fuente: The Phoenix Doctrine v1.1]. La doctrina nombra explícitamente como enemigo el modelo de consultoría que vende tiempo y horas-hombre como medida de valor.
Esperar a tener claridad. La parálisis disfrazada de prudencia. El director que dice "primero quiero entender bien" normalmente está racionalizando el miedo a equivocarse, y en esta transición el error de no actuar es mayor que el error de actuar mal y corregir [fuente: The Phoenix Doctrine v1.1].
Confundir modernización de TI con pivote estratégico. Es la brecha de alfabetización más común a nivel de directorio: evaluar la inversión en IA como una línea de gasto y no como un cambio en el conjunto de capacidades de la organización [fuente: AI Literacy A Multi-Dimensional Analysis of Governance, Revenue Systems, and Epistemic Rigor in the Agentic Era]. Se aprueba una migración y se registra en acta como transformación.
3. Qué exigir en una propuesta, antes de firmar
Siete exigencias. Ninguna requiere conocimiento técnico para formularse, y todas son verificables por un tercero.
Línea base medida antes de instalar nada. La cifra del proceso hoy: coste, tiempo de ciclo, volumen, tasa de error, con método y fecha. Sin línea base previa, ninguna mejora posterior es demostrable, y la conversación de retorno se vuelve una negociación de anécdotas.
Criterio de éxito escrito como tasa, no como adjetivo. Un sistema agéntico no es determinista: el mismo encargo puede producir resultados distintos, y por eso se verifica con un conjunto curado de casos reales con resultado esperado que produce una tasa, no un veredicto [fuente: Evals Ingeniería de Confiabilidad y Evaluación de Sistemas Agénticos]. La definición operativa que conviene adoptar en el directorio es dura y útil: un piloto es un sistema sin evals — funcionó en la demo porque nadie midió el resto de la distribución.
Coste total, incluyendo lo que va bajo la línea de flotación. Hay tres partidas que las propuestas omiten con regularidad: el reentrenamiento por deriva del modelo, del orden del 22% de sobrecoste continuo; el multiplicador de datos y gobierno, que exige cerca de cuatro dólares de inversión en fundaciones de datos por cada dólar puesto en modelos; y el arrastre de deuda técnica por integración con sistemas heredados, en torno al 29% del retorno [fuente: AI Literacy A Multi-Dimensional Analysis of Governance, Revenue Systems, and Epistemic Rigor in the Agentic Era]. Un precio que solo cubre licencias e implementación es un precio incompleto, no un precio bajo.
Opcionalidad contractual. Cláusulas de salida, portabilidad de datos, arquitectura modular, capacidad de cambiar de proveedor en semanas y no en años. La tentación de comprometerse con un solo stack a cambio de descuento o "integración profunda" es la trampa más cara de esta era [fuente: DAL OS v1 0]. La libertad estructural de elegir cuando llegue el momento de elegir vale más que cualquier descuento por exclusividad.
Skin in the game del proveedor. Una parte del honorario vinculada al resultado. Un proveedor que cobra lo mismo si funciona y si no funciona ya puso precio a su propia indiferencia. La doctrina lo formula al revés y es más exigente: no se puede exigir piel en el juego al cliente y cobrar el cien por ciento del fee con independencia del resultado [fuente: DAL OS v1 0].
Registro inmutable y legible. Cada ejecución debe dejar traza: qué contexto se cargó, qué decidió, qué herramienta invocó con qué argumentos, cuánto costó, dónde intervino un humano. Ese registro tiene tres consumos — depurar el fallo, aprender de él y defenderse ante un auditor o un regulador. Un sistema sin registro inmutable no es auditable, y un sistema no auditable no debería operar sin supervisión humana directa [fuente: Evals Ingeniería de Confiabilidad y Evaluación de Sistemas Agénticos].
Supervisión humana real, no decorativa. Mecanismo de detención, capacidad de anular la decisión de la máquina, y un aprobador con formación, contexto y horas asignadas. La supervisión decorativa — aprobadores sin formación ni contexto que firman todo — es peor que no tener supervisión, porque produce evidencia falsa de control, y es el primer hallazgo que un auditor busca [fuente: Organización Humano-Agente La Empresa Híbrida y el Rediseño del Trabajo].
4. Cuestionario de diligencia para un proveedor de IA
Trece preguntas. La tercera columna es la parte útil: no describe una mala respuesta, describe la respuesta que termina la conversación.
| Pregunta al proveedor | Qué está probando | Respuesta que descalifica |
|---|---|---|
| ¿Cuál es la línea base de este proceso, medida antes de instalar nada, y con qué método? | Si existe aparato de medición o solo relato | "La medimos después del despliegue" · una estimación sin método ni fecha |
| ¿Qué tasa de éxito sostiene el sistema sobre casos reales nuestros, y sobre cuántos casos? | Si hay evals o solo demo | Una demostración en vez de una cifra · "funciona muy bien" · casos de laboratorio |
| ¿Quién juzga si funcionó, y es independiente de quien lo construyó? | Separación estructural juez/constructor | El mismo equipo que construye evalúa su propio trabajo |
| ¿Cuánto cuesta una tarea exitosa, contando los intentos fallidos? | Economía real frente a economía de folleto | Coste por licencia o por usuario como única cifra |
| ¿Qué parte del precio cubre reentrenamiento por deriva, gobierno de datos e integración con sistemas heredados? | Si el precio está completo | "Está todo incluido", sin desglose de esas tres partidas |
| Si en nueve meses cambiamos de proveedor, ¿qué se lleva la empresa, en qué formato y en cuánto tiempo? | Opcionalidad real | "Sus datos son exportables", sin plazo, sin formato y sin los casos de evaluación acumulados |
| ¿Qué parte de su honorario depende de que esto funcione? | Skin in the game | Ninguna · un descuento retroactivo simbólico |
| ¿Qué proceso nuestro deja de existir cuando esto entre en operación? | Si es rediseño o una capa encima | "Ninguno, esto se suma a lo que ya hacen" |
| ¿Quién de nuestra empresa queda como responsable del sistema, y qué debe saber para serlo? | Si la capacidad se instala o se alquila | "Nosotros lo operamos por ustedes", presentado como ventaja |
| ¿Qué registro queda de cada decisión del sistema, y quién de los nuestros puede leerlo sin ayuda de ustedes? | Auditabilidad y forense | Registro accesible solo desde su plataforma · "el modelo es una caja negra" |
| ¿Cómo se detiene, quién lo detiene y en cuánto tiempo? | Supervisión efectiva | No hay mecanismo definido · la detención depende de un ticket de soporte |
| ¿Cuántas intervenciones humanas al día consume en régimen, y de cuántos minutos? | Coste oculto de supervisión | "Es totalmente autónomo" · no lo han medido |
| ¿Qué salió mal en su última implementación y qué cambiaron después? | Honestidad operativa y aprendizaje | "Nunca nos ha salido mal" |
Regla de uso: las tres primeras preguntas son eliminatorias. Si no hay línea base, tasa sobre casos propios y juez independiente, las diez restantes son decoración sobre un piloto.
5. Cómo saber, después, si lo implementado funciona
"Funciona" no es un estado. Es una tasa que decae: el 91% de los sistemas de aprendizaje automático experimenta degradación medible en sus primeros doce meses [fuente: The Phoenix Doctrine v1.1]. Una verificación única al cierre del proyecto mide el mejor día del sistema, no su comportamiento.
El tablero mínimo que un directorio debe pedir con la misma naturalidad con que pide el reporte financiero son cinco indicadores [fuente: Evals Ingeniería de Confiabilidad y Evaluación de Sistemas Agénticos]:
Tasa de éxito por tarea sobre casos reales, no sobre el conjunto de aceptación original. Es el número que gobierna cuánta autonomía merece el sistema.
Tasa de intervención humana. Cuánta supervisión consume realmente. Es el coste que nunca aparece en la propuesta.
Coste por tarea exitosa. Los fallos también se pagan. Esta cifra, y no la factura mensual de la plataforma, es la que se compara contra la línea base.
Tiempo a detección. Cuánto tarda la organización en notar un desvío. Define el riesgo operativo real.
Deriva semanal. La tendencia de los cuatro anteriores. Es la alarma temprana.
A esos cinco indicadores conviene añadir cuatro afirmaciones de cierre, que son más difíciles de maquillar que cualquier métrica [fuente: DAL OS v1 0]: se ejecutó destrucción real, con fecha y firma — un proceso terminó, un contrato se canceló, un producto se retiró; el sistema quedó más antifrágil en términos que el propio equipo puede articular sin ayuda del proveedor; la capacidad de la gente subió de forma verificable en la práctica; y la organización puede operar sin el proveedor. Una intervención que termina con el cliente diciendo "los necesitamos para todo lo demás" se vendió bien y falló.
6. Qué no comprar
No comprar modernización de TI etiquetada como pivote estratégico. No comprar transformaciones de tres años con presupuesto masivo y retorno lineal prometido. No comprar exclusividad de stack a cambio de descuento. No comprar un piloto más: si el anterior no tiene tasa medida, el siguiente tampoco la tendrá. No comprar capacitación de evento único sin refuerzo ni evidencia — la Research_Base la nombra sin eufemismos como placebo de habilidades [fuente: Organización Humano-Agente La Empresa Híbrida y el Rediseño del Trabajo]. Y no comprar autonomía sobre procesos cuyo registro no se puede leer: la delegación sin traza no es eficiencia, es exposición.
Hay una compra que sí merece defenderse en el directorio y casi nunca se propone: la de rediseño, formación y supervisión. Una cartera que destina el 90% a licencias y modelos y el 10% a personas y procesos está invertida respecto de donde está el valor, y predice el fracaso del piloto [fuente: Organización Humano-Agente La Empresa Híbrida y el Rediseño del Trabajo]. La heurística de referencia reparte el éxito en torno a 10% algoritmo, 20% tecnología y datos, 70% personas y procesos; la propia fuente pide leerla como orden de magnitud y no como medición.
7. Qué hacer el lunes
- Pedir el inventario de sistemas de IA en operación, con un nombre por sistema. No un área: una persona. Un agente sin responsable es shadow AI con presupuesto [fuente: Organización Humano-Agente La Empresa Híbrida y el Rediseño del Trabajo].
- Pedir los cinco indicadores de la sección 5 para cada uno. Si no existen, esa es la primera decisión del directorio, y es más barata que cualquier proyecto nuevo.
- Aplicar el cuestionario de la sección 4 a la propuesta que hoy está sobre la mesa, no a la próxima. Registrar en acta qué preguntas quedaron sin respuesta.
- Pedir el desglose de la cartera de IA entre licencias y modelos, por un lado, y rediseño, formación y supervisión, por otro. La proporción es el diagnóstico.
- Exigir la línea base medida de un solo proceso antes del cierre del trimestre. Uno, elegido por su volumen y su coste, no por su vistosidad.
- Dejar constancia del fundamento de cada recomendación asistida por IA que reciba el directorio. La trazabilidad de la recomendación algorítmica es hoy obligación fiduciaria documentada, no buena práctica [fuente: AI Literacy A Multi-Dimensional Analysis of Governance, Revenue Systems, and Epistemic Rigor in the Agentic Era].
- Ejecutar un acto de destrucción con fecha y firma. Un proceso que termina, un contrato que se cancela, un informe que deja de producirse. La diferencia entre una organización que dice destruir y una que destruye es siempre esa firma [fuente: DAL OS v1 0].
Qué no hemos cubierto aquí
Este documento se detiene en la puerta de la sala del directorio. No cubre lo que ocurre cuando la decisión baja: una decisión aprobada aquí llega a la alta gerencia como presupuesto y plazo, sin los criterios con que se tomó, y cada gerencia la completa con el criterio que tiene a mano. Ese es un problema distinto, con su propio documento.
Tampoco cubre la arquitectura interna de lo que se compra — anatomía del agente, seguridad agéntica, ingeniería de contexto, niveles de autonomía — que es materia de quien construye, no de quien aprueba. No cubre el régimen regulatorio aplicable fuera de la Unión Europea, cuyo AI Act es la referencia usada aquí por ser hoy el estándar global de facto. Y no cubre cómo se instala en un directorio la capacidad de sostener estas preguntas sin asistencia externa, que es el trabajo de Phoenix PEEx, de VoltAi Academy.