Plan de adopción de IA para tu empresa: roadmap de 90 días del diagnóstico al primer resultado medible

Noventa días son una herramienta de planificación, no una garantía. Un caso que depende de contratos, datos regulados, integraciones complejas o infraestructura nueva puede necesitar más tiempo. Otro basado en una función empresarial ya disponible puede demostrar valor antes.

La disciplina consiste en mantener el alcance estrecho, hacer visibles las dependencias y no confundir actividad con avance.

# Qué debe existir al terminar los 90 días

Una empresa no necesita salir del periodo con “IA en toda la organización”. Debe tener:

• un problema y una línea base documentados;
• un propietario de negocio y responsables técnicos;
• datos, sistemas y usuarios delimitados;
• una herramienta o arquitectura seleccionada con criterio;
• un conjunto de evaluación y resultados;
• revisión humana, límites y ruta de incidente;
• evidencia de uso en un grupo controlado;
• costos observados y dependencias;
• documentación de operación;
• una decisión ejecutiva sobre el siguiente paso.

Si falta la evidencia necesaria para continuar, detener o rediseñar también es un resultado válido.

# Antes del día 1: condiciones de entrada

El reloj no debe comenzar con una idea sin dueño. Confirma:

1. patrocinador con capacidad de resolver bloqueos;
2. propietario del proceso y usuarios disponibles;
3. acceso autorizado a ejemplos representativos;
4. línea base que pueda medirse;
5. herramientas o presupuesto para evaluar opciones;
6. participación de seguridad, privacidad, legal o cumplimiento según el caso;
7. tiempo del equipo para revisar y practicar.

Si estas condiciones no existen, usa la primera fase para construirlas y ajusta el objetivo. Forzar el calendario puede producir una demo que nadie puede operar.

# Horizonte 1 — Días 1 a 30: definir y preparar

# Mapear el proceso real

Documenta entradas, actividades, decisiones, excepciones, sistemas y salida. Observa cómo trabaja la gente, no solo el procedimiento formal. Registra volumen, tiempo, errores, retrabajo y consecuencias.

# Seleccionar un caso

Evalúa valor, viabilidad y riesgo. Un buen primer caso tiene resultado verificable, acceso a datos, propietario y posibilidad de corrección antes de causar daño.

Evita elegir únicamente por visibilidad ejecutiva. Analizar llamadas, extraer campos de documentos o asistir en búsquedas internas pueden ser candidatos, pero su conveniencia depende del proceso concreto.

# Definir la línea base

Mide el proceso actual. Si el objetivo es ahorrar tiempo, toma una muestra de duración. Si es mejorar calidad, define qué errores cuentan y con qué frecuencia ocurren. Si es acelerar respuesta, registra el ciclo completo.

# Preparar datos y permisos

Selecciona ejemplos representativos, identifica información sensible y documenta quién autoriza su uso. No es necesario limpiar todos los datos de la empresa; delimita los que necesita el piloto.

# Diseñar evaluación y controles

Antes de construir, define qué salida es aceptable, quién revisa, qué no puede hacer el sistema y cómo se registra un error. El NIST AI RMF propone gobernar, mapear, medir y gestionar riesgos de forma continua; estas funciones deben aparecer desde el diseño.

# Puerta de decisión 1

Al final del horizonte, decide:

• avanzar, si existen datos, propietario y criterio de evaluación;
• reducir alcance, si hay valor pero demasiadas dependencias;
• preparar primero, si faltan datos, política o acceso;
• detener, si el problema no justifica el costo o el riesgo.

# Horizonte 2 — Días 31 a 60: construir y evaluar

# Desarrollar el flujo mínimo

Construye la menor versión que permita probar la hipótesis. Puede ser una configuración de una plataforma, una automatización o una integración. No agregues funciones que no cambien la decisión.

# Separar ambientes y accesos

Usa datos de prueba o un conjunto controlado. Separa credenciales y evita escribir en sistemas productivos hasta validar. Los permisos deben limitarse al caso.

# Crear ejemplos de referencia

Personas con conocimiento del proceso preparan respuestas o decisiones esperadas. Incluye casos normales, excepciones y entradas difíciles. Esta colección permite comparar versiones y detectar regresiones.

# Evaluar calidad y fallas

Mide precisión relevante para la tarea, omisiones, invenciones, consistencia, latencia y costo. Documenta por qué falla, no solo cuánto.

# Operar en modo sombra

El sistema produce resultados sin ejecutar acciones o los guarda como borrador. El equipo compara con su trabajo habitual y registra correcciones. Esto reduce riesgo y ofrece una base realista.

La guía de AWS para el ciclo de vida de IA generativa separa actividades de desarrollo, preproducción, producción y operación; la distinción ayuda a no tratar una prueba como despliegue.

# Puerta de decisión 2

Avanza a usuarios controlados si el flujo cumple umbrales, las fallas son entendibles y existen mecanismos de soporte y reversión. Si no, ajusta el caso o detén antes de integrar más sistemas.

# Horizonte 3 — Días 61 a 90: adoptar y decidir

# Probar con usuarios y volumen limitados

Selecciona un grupo representativo, explica alcance y límites, y observa el flujo completo. La capacitación debe incluir verificación, escalamiento e incidentes, no solo uso de la herramienta.

# Integrar con prudencia

Habilita primero acciones reversibles: guardar un borrador, añadir una etiqueta o proponer una tarea. Los cambios que afectan clientes, dinero, contratos, derechos o seguridad requieren mayor control.

# Medir el resultado operativo

Compara con la línea base:

# Documentar y transferir

Entrega arquitectura, configuraciones, datos de prueba, criterios de evaluación, runbook, responsables, costos, riesgos y decisiones. La empresa debe poder entender qué existe y cómo detenerlo.

# Puerta de decisión 3

El cierre debe resolver una de cuatro rutas:

• escalar con controles y presupuesto definidos;
• mantener el alcance mientras se acumula evidencia;
• ajustar proceso, datos, herramienta o experiencia;
• retirar el piloto y conservar los aprendizajes.

# Plan semanal orientativo

La secuencia puede solaparse, pero no elimines las puertas de decisión para cumplir una fecha.

# Roles mínimos

Una persona puede cubrir varios roles en equipos pequeños, pero la responsabilidad debe quedar explícita.

# Qué no intentar en 90 días

• automatizar varios procesos sin relación;
• limpiar todos los datos de la organización;
• desplegar un agente con permisos amplios;
• prometer ROI antes de medir la línea base;
• migrar sistemas sin que el caso lo requiera;
• capacitar a toda la empresa antes de validar el flujo;
• declarar producción únicamente porque la demo funciona;
• omitir seguridad o privacidad para ganar velocidad.

# Cómo evitar que el piloto quede aislado

Desde el inicio, registra decisiones y dependencias que afectarían producción: identidad, integración, observabilidad, soporte, contrato, costos, datos y retiro. No hace falta construir todo durante el piloto, pero sí saber qué faltaría.

El modelo de madurez de adopción de Microsoft considera estrategia, proceso, gobierno, tecnología y cultura. Esa mirada evita que un resultado técnico positivo se interprete como preparación organizacional completa.

# Ajustar el plan según el nivel de riesgo

La secuencia puede mantenerse, pero la profundidad cambia. Un asistente que resume documentos públicos puede probarse con controles ligeros; un sistema que usa datos sensibles, recomienda decisiones sobre personas o ejecuta acciones necesita más revisión, evidencia y autoridad.

Antes de fijar el calendario, evalúa:

• severidad y reversibilidad de un error;
• personas que pueden resultar afectadas;
• sensibilidad y finalidad de los datos;
• autonomía y permisos del sistema;
• dependencia de terceros;
• obligaciones regulatorias o contractuales;
• capacidad para detectar y contener incidentes.

El caso de mayor riesgo no siempre debe ser el primero. Puede convenir iniciar con una parte informativa o de apoyo que genere aprendizaje sin automatizar la decisión sensible.

# Preparar la transición a operación

La última semana no debería dedicarse únicamente a presentar resultados. Debe comprobar que alguien puede operar el flujo después del proyecto.

Verifica:

• cuentas y credenciales bajo control de la organización;
• responsables y suplentes;
• monitoreo, alertas y tablero mínimo;
• procedimiento para fallas y degradación;
• actualización de instrucciones, modelos o conectores;
• soporte de proveedores y escalamiento interno;
• costos recurrentes y límites presupuestales;
• respaldo de configuraciones y documentación;
• mecanismo de retiro y conservación de registros.

Si producción pertenece a otro equipo, realiza una transición explícita y registra lo que no fue probado. Un piloto documentado puede ser apto para decisión sin ser todavía apto para operación.

# Preguntas frecuentes

# ¿Se puede implementar IA en 90 días?

Se puede validar un caso bien delimitado y, en algunos contextos, ponerlo en operación controlada. No se puede garantizar el resultado sin revisar datos, sistemas, riesgo y disponibilidad del equipo.

# ¿Cuántos pilotos deben ejecutarse?

No hay una cifra universal. Un solo caso con buena medición suele producir más aprendizaje que varios flujos superficiales.

# ¿Qué pasa si no hay datos suficientes?

Reduce el alcance, usa datos autorizados de referencia o dedica el periodo a preparación. Inventar una validación crea una decisión falsa.

# ¿El piloto debe usar la herramienta definitiva?

No siempre, pero debe revelar dependencias relevantes. Si la prueba elimina seguridad, integración o volumen, no representa producción.

# ¿Qué es un resultado medible?

Un cambio observado frente a la línea base con método y periodo definidos: tiempo, calidad, volumen, costo, riesgo o resultado del proceso.

# Noventa días para decidir mejor

El valor del plan no está en cumplir cada fecha exacta. Está en obligar a convertir una idea en evidencia, con responsables y decisiones explícitas.

ia¹ estructura diagnósticos y pilotos con línea base, evaluación, integración, capacitación y gobierno. Solicita un diagnóstico y roadmap de IA.

# Fuentes primarias

• NIST — AI Risk Management Framework Core
• AWS — Generative AI Lifecycle Operational Excellence
• AWS — Preproduction phase
• Microsoft — Agentic AI adoption maturity model