La pregunta más común que recibimos no es “¿qué puede hacer la IA en mi empresa?”, sino “¿por dónde empiezo?”. Esta guía responde exactamente eso: un plan operativo de 90 días para llevar la inteligencia artificial desde la idea hasta procesos funcionando en producción. Si todavía estás explorando el tema en general, parte por nuestra guía completa de IA para empresas chilenas. Si ya decidiste avanzar y quieres saber cómo se hace en concreto — sigue aquí.
Por qué 90 días (y no 6 meses ni 2 años)
Los plazos largos matan proyectos de IA antes de que generen valor. Cuando una empresa se plantea “vamos a implementar IA” como un proyecto de 18 meses, ocurren tres cosas predecibles: los stakeholders pierden interés, las prioridades cambian a mitad de camino y el equipo termina justificando inversiones que ya no se sostienen contra resultados reales.
Noventa días es el plazo correcto por una razón concreta: es lo suficientemente largo para construir un piloto bien hecho con métricas reales, y lo suficientemente corto para que la atención organizacional no se disperse. Tres meses calendario. Un trimestre. Un ciclo de reporting de gerencia.
El objetivo de los primeros 90 días no es implementar IA en toda la empresa. Es probar UN proceso bien elegido, medir el impacto contra KPIs definidos, y tomar una decisión informada sobre si escalar, ajustar o parar. La diferencia entre las empresas que terminan usando IA productivamente y las que se quedan con presentaciones bonitas suele estar acá: las primeras tratan los primeros 90 días como un experimento serio, las segundas los tratan como una fase de “exploración” sin entregables claros.
Día 0-15 — Diagnóstico: qué procesos analizar primero
Las primeras dos semanas son para mirar tu empresa con honestidad. No para diseñar la solución todavía — para mapear el terreno.
Qué procesos auditar (y cuáles ignorar de momento)
Hay un criterio simple para priorizar procesos en el diagnóstico inicial: busca procesos con alto volumen, alta repetición y bajo valor estratégico. Esos son los candidatos a automatizar primero. Lo que NO buscas en esta fase son procesos creativos, estratégicos o de relacionamiento complejo — esos vienen después, si vienen.
Ejemplos concretos del tipo de proceso que conviene mapear primero:
- Respuestas repetitivas a clientes por WhatsApp, email o chat (cotizaciones estándar, preguntas frecuentes, agendamiento).
- Clasificación y enrutamiento de documentos (facturas, correos, formularios).
- Generación de reportes recurrentes que alguien arma a mano.
- Validación de datos antes de cargarlos a un sistema.
- Búsqueda de información en documentos largos (contratos, manuales, normativas).
Lo que NO conviene incluir en el primer piloto: cualquier proceso que requiera juicio humano matizado, que toque temas legales o financieros sensibles sin supervisión, o que tenga un volumen tan bajo que el ROI sea irrelevante.
Qué información recolectar en el diagnóstico
Por cada proceso candidato, levantar: cuántas horas semanales consume, cuántas personas lo ejecutan, qué herramientas usa hoy, qué nivel de error tiene, qué pasaría si se demora un día más en hacerse. Con esos cinco datos se puede decidir cuáles procesos vale la pena automatizar y cuáles no, sin necesidad de ningún análisis sofisticado.
El error frecuente en esta fase es delegar el levantamiento a una sola persona que “ya conoce los procesos”. Funciona mejor entrevistar a quien efectivamente ejecuta el proceso día a día — habitualmente quien está más abajo en el organigrama es quien tiene el detalle real. Para profundizar en cómo se estructura este tipo de diagnóstico, revisa cuánto cuesta una consultoría de IA en Chile: la fase de diagnóstico es la primera etapa de una consultoría bien hecha.
Día 16-30 — Selección del caso piloto: 5 criterios para elegir bien
Con el mapa de procesos del diagnóstico, ahora viene la decisión más importante de los 90 días: cuál es el primer proceso que se va a automatizar. Esta decisión define si el piloto será un éxito comunicable o un experimento que se queda en el cajón.
Los 5 criterios
- Volumen suficiente: El proceso ocurre al menos varias veces por semana. Si es algo que pasa una vez al mes, el ROI no va a ser visible en 90 días.
- Bajo riesgo si falla: Un error del sistema no genera consecuencias graves para clientes, finanzas o cumplimiento legal. Idealmente, hay supervisión humana fácil.
- Datos disponibles: Existe historial digital del proceso. Si los datos están solo en cabezas o en planillas dispersas, primero hay que digitalizarlos — y eso es otro proyecto.
- Stakeholder visible: Hay una persona en la empresa que se hace dueña del piloto y que tiene autoridad para tomar decisiones rápidas. Sin dueño claro, el piloto se queda esperando aprobaciones.
- Métrica obvia de éxito: Antes de empezar, se puede definir UN número que va a moverse si el piloto funciona (horas ahorradas por semana, % de respuestas automatizadas, tiempo promedio de primera respuesta).
Cómo decidir entre varios candidatos
Si después de aplicar los 5 criterios quedan 2 o 3 procesos viables, elegir el que tiene mayor visibilidad organizacional. Un piloto exitoso en atención al cliente lo ve todo el mundo; un piloto exitoso en clasificación de PDFs internos solo lo ve el equipo de operaciones. Para los primeros 90 días, la visibilidad importa tanto como el ahorro real — porque va a definir si el siguiente proyecto recibe presupuesto o no.
Día 31-60 — Construcción del piloto: qué hacer cada semana
Cuatro semanas para construir la primera versión funcional. Es poco tiempo para mucha gente acostumbrada a ciclos de desarrollo largos. Funciona si se respeta una estructura simple por semana:
Semana 5 — Diseño funcional y arquitectura
Definir exactamente qué hace el sistema: entradas, salidas, flujos, casos límite. En esta semana NO se escribe código todavía — se escribe el documento de “qué va a hacer esto”. Si el documento no se entiende solo cuando lo lee un tercero, no está listo. El error más caro de la fase de construcción es saltar este paso para “ganar tiempo”.
Semana 6 — Construcción del MVP
Implementación de la versión mínima que cumple el flujo principal. No incluye casos borde, no incluye UI bonita, no incluye reportes — solo el flujo central funcionando de punta a punta. Si el proyecto es automatización de WhatsApp, por ejemplo, esta es la semana donde el bot ya recibe mensajes y los procesa con la lógica básica. Para profundizar en cómo se estructura un proyecto de este tipo, revisa nuestra guía sobre cómo automatizar WhatsApp en tu empresa con IA.
Semana 7 — Pruebas internas
El equipo interno (no clientes todavía) usa el sistema en escenarios controlados. Se documentan los errores, las inconsistencias, los casos donde el sistema responde mal. Lo importante: NO arreglar todo lo que aparece. Priorizar lo que rompe el flujo principal y dejar lo accesorio para la semana siguiente o para post-piloto.
Semana 8 — Ajustes y preparación para piloto real
Cierre de los bugs críticos de la semana 7, integración con los sistemas reales (CRM, ERP, WhatsApp API o lo que corresponda), preparación de la documentación mínima para el equipo que va a usar el sistema. Al final de esta semana, el piloto está listo para ir a usuarios reales.
Día 61-90 — Medir, ajustar, escalar: las 4 métricas que sí importan
Las últimas cuatro semanas son las que definen si el proyecto se queda en la empresa o se descarta. Acá es donde el piloto se enfrenta con la realidad: usuarios reales con casos reales que el equipo no anticipó.
Las 4 métricas que sí importan
Hay muchas métricas que se pueden medir. La mayoría son ruido. Las cuatro que sí mueven decisiones son:
- Tasa de resolución automática: ¿qué porcentaje de los casos los maneja el sistema sin necesidad de intervención humana? Es la métrica directa de cuánto trabajo está liberando.
- Tiempo promedio de primera respuesta: aplicable a procesos de atención. Si bajó significativamente, hay valor. Si quedó igual, hay un problema.
- Tasa de error del sistema: ¿cuántas veces el sistema entrega una respuesta incorrecta? Una tasa de error baja con baja tasa de resolución es preferible a alta resolución con errores frecuentes — los errores destruyen confianza más rápido que la ausencia de respuesta.
- Satisfacción del usuario final: medida con NPS, encuesta corta post-interacción, o reclamos espontáneos. Es el filtro de realidad: el sistema puede tener métricas técnicas perfectas y aun así estar frustrando a los clientes.
Cómo decidir si se sigue, se ajusta o se para
Al final del día 90 hay tres posibles decisiones:
- Seguir y escalar: las métricas mejoraron respecto al baseline, los usuarios no reportan problemas graves. Próximo paso es expandir a más volumen o a procesos similares.
- Seguir pero ajustar: hay valor evidente pero también problemas claros. Otros 30-60 días para refinar antes de escalar.
- Parar: las métricas no mejoraron significativamente o los problemas son estructurales. Aprender de la experiencia, documentar qué falló y elegir mejor el próximo caso. Esta decisión NO es un fracaso — es la razón por la que los pilotos existen.
Errores que matan el proyecto antes del día 90
Los problemas que matan proyectos de IA en empresas chilenas son predecibles y casi siempre los mismos. Conocerlos por adelantado es la forma más barata de evitarlos.
Querer automatizar todo desde el día uno
La tentación de “como vamos a hacer IA, automatizamos los cinco procesos más dolorosos” es fuerte. Es también la receta más segura para que nada termine funcionando bien en 90 días. Un proceso bien resuelto vale más que cinco a medias.
Falta de un dueño claro del piloto
Cuando “todos están a cargo”, nadie está a cargo. El piloto necesita una persona con autoridad para decidir rápido, defender el proyecto frente al resto de la organización y tomar la decisión final al día 90. Sin esa persona, las decisiones se atrasan y los plazos se estiran.
Definir métricas de éxito después de implementar
Si las métricas se definen recién en la semana 10 cuando ya hay resultados, siempre se eligen las métricas que mejor se ven. Las métricas tienen que estar definidas en el día 15, máximo, junto con la selección del caso piloto. Sin baseline previo no hay forma honesta de saber si el piloto funcionó.
Contratar al proveedor más barato sin entender qué entrega
El precio bajo casi siempre esconde alcance recortado, falta de soporte post-implementación o uso de herramientas de terceros que generan dependencia. Esto no significa que el más caro sea mejor — significa que el precio sin contexto no dice nada. La forma correcta de comparar es alcance contra alcance, con entregables explícitos y plazos definidos.
No considerar el cambio operativo en el equipo
Un proyecto de IA bien implementado cambia cómo trabaja la gente. Si el equipo no sabe qué pasa con sus tareas actuales, qué se espera de ellos en el nuevo flujo o cómo se mide su desempeño, el piloto enfrenta resistencia silenciosa que termina matando la adopción. La gestión del cambio empieza el día 0, no el día 90.
Costos esperados por fase (rangos en CLP)
Los rangos siguientes son referenciales para empresas chilenas, mayo 2026. El precio final varía según industria, integraciones requeridas y complejidad del proceso elegido.
| Fase | Duración | Rango CLP |
|---|---|---|
| Diagnóstico inicial (Día 0-15) | 2 semanas | $400.000 – $800.000 |
| Selección + diseño del piloto (Día 16-30) | 2 semanas | $600.000 – $1.200.000 |
| Construcción del piloto (Día 31-60) | 4 semanas | $2.000.000 – $5.000.000 |
| Medición + ajustes (Día 61-90) | 4 semanas | $800.000 – $1.800.000 |
| Mantenimiento post-piloto | Mensual | $120.000 – $450.000/mes |
El rango total para los 90 días completos puede ir desde $3.800.000 CLP en proyectos acotados hasta más de $8.800.000 CLP en proyectos complejos con múltiples integraciones. Para entender qué incluye cada fase y cómo cotizar bien, revisa nuestra guía sobre precios de consultoría IA en Chile.
Cómo armar el equipo interno (3 roles mínimos)
No se puede subcontratar todo. El proveedor externo aporta capacidad técnica, pero hay tres roles que tienen que existir dentro de la empresa para que el proyecto funcione.
1. Sponsor ejecutivo
Una persona de la capa directiva (gerencia general, gerencia de operaciones, gerencia comercial — depende del proceso elegido) que aprueba presupuesto, desbloquea decisiones políticas dentro de la empresa y defiende el proyecto frente al resto del comité gerencial. No tiene que estar en el día a día — tiene que estar disponible cuando se necesita una decisión rápida.
2. Product owner operativo
La persona que vive el proceso en el día a día y se hace dueña del piloto durante los 90 días. Toma decisiones de detalle, valida el comportamiento del sistema, transmite el feedback de usuarios al proveedor técnico. Idealmente con dedicación de al menos 30-40% de su tiempo durante los 90 días.
3. Referente técnico
Alguien del área de TI o sistemas que entienda la infraestructura actual, los accesos, las integraciones disponibles. No tiene que ser programador — tiene que ser quien le abre las puertas al proveedor para que pueda integrarse con lo que ya existe sin pelear con permisos durante semanas.
Cumplimiento de la Ley 21.719 desde el día 0
Si el proyecto toca datos personales — y la mayoría de los proyectos de IA lo hacen — el cumplimiento de la Ley 21.719 no es algo que se incorpora al final. Se incorpora en el diseño desde la primera semana, porque rediseñar para cumplir después siempre cuesta más caro que diseñar con cumplimiento desde el inicio.
La Ley 21.719 entra en plena vigencia el 1 de diciembre de 2026, después de un periodo de vacancia legal de 24 meses. Eso significa que cualquier piloto que arranque en mayo o junio de 2026 debería estar listo para operar bajo la nueva norma cuando esté en producción. Las multas en caso de incumplimiento van desde 5.000 UTM (infracciones leves) hasta 20.000 UTM (gravísimas), con reincidencia que puede llegar al 2-4% de los ingresos anuales de la empresa.
En términos prácticos, el diseño del piloto tiene que considerar cuatro elementos mínimos: consentimiento explícito antes de tratar datos personales, registro auditable de ese consentimiento, opción de baja en cada interacción de marketing y eliminación de datos cuando el titular lo solicita. Si tu proyecto es automatización de WhatsApp o chatbot de atención, todos estos elementos deberían estar en el flujo de la semana 5 (diseño funcional), no como un parche en la semana 12.
Qué hacer después del día 90 — escalamiento por fases
Si la decisión al día 90 fue “seguir y escalar”, lo que viene NO es “implementar IA en toda la empresa”. Es expandir el piloto exitoso a más volumen, más usuarios o procesos adyacentes, manteniendo la disciplina de medir cada paso.
Un escalamiento ordenado típicamente sigue esta lógica:
- Mes 4: escalar el mismo proceso a más volumen o más usuarios.
- Mes 5-6: agregar un segundo proceso similar al primero, aprovechando lo aprendido.
- Mes 7-9: evaluar un proceso de mayor complejidad (con más integraciones o más matiz).
- Mes 10-12: consolidar la operación y empezar a pensar en automatizaciones más ambiciosas.
El error frecuente post-piloto es saltar directo al “ahora hagámoslo todo”. Las empresas que escalan IA con éxito son las que se mantienen disciplinadas en hacer una cosa a la vez, bien hecha, antes de pasar a la siguiente. Si quieres evaluar opciones de proveedor para escalar después del piloto, te puede servir nuestro overview de empresa de inteligencia artificial en Chile con criterios para comparar.
Preguntas frecuentes
¿Se puede hacer todo el proceso de 90 días sin un proveedor externo?
Técnicamente sí, si la empresa tiene equipo interno con experiencia en IA. En la práctica, la mayoría de las empresas chilenas no tiene ese perfil de forma estable y termina perdiendo más tiempo en la curva de aprendizaje que lo que ahorraría sin contratar afuera. La decisión depende del tamaño de la empresa: bajo 50 personas, casi siempre conviene proveedor externo. Sobre 200 personas, puede tener sentido construir capacidad interna en paralelo a un proveedor que acelere el primer piloto.
¿Qué pasa si al día 90 el piloto no funciona?
Se documenta qué falló y por qué, y se decide si vale la pena intentar con otro proceso o pausar el tema. Un piloto que no funciona no es dinero perdido si se aprende algo útil sobre la operación. Lo que sí es dinero perdido es no medir nada, no aprender nada y volver a empezar desde cero en seis meses con otro proveedor.
¿Cuántas personas de mi equipo necesito dedicar al proyecto?
Mínimo tres roles (sponsor, product owner operativo, referente técnico) con dedicaciones que van desde 5% hasta 40% del tiempo según el rol. En total, durante los 90 días, una empresa típica dedica entre 0,5 y 1,5 personas equivalentes a tiempo completo. Si la respuesta es “no podemos dedicar a nadie”, el proyecto no va a funcionar — independientemente de qué proveedor se contrate.
¿La IA reemplaza puestos de trabajo en estos 90 días?
En los primeros 90 días, prácticamente nunca. Los pilotos bien diseñados liberan tiempo del equipo, no eliminan personas. Lo que ocurre es que el tiempo liberado se redirige a trabajo de mayor valor — tareas que antes no se hacían porque no había tiempo. Las decisiones sobre estructura de equipo a más largo plazo son una conversación distinta y posterior, no parte del piloto.
¿Y si mi empresa es muy pequeña? ¿También aplica este plan de 90 días?
Sí, con ajustes de escala. Una PYME de 10 personas puede hacer el mismo plan con menor presupuesto y procesos más acotados. La estructura de 4 fases sigue siendo válida — lo que cambia es la magnitud de cada fase. Para empresas muy pequeñas, las implementaciones de chatbot o automatización WhatsApp son el punto de entrada habitual porque tienen ROI visible rápidamente.
¿Qué tecnologías se usan típicamente en estos pilotos?
Depende mucho del proceso, pero hay un stack común: modelos de lenguaje (GPT, Claude, Gemini) para tareas conversacionales y de procesamiento de texto, plataformas de automatización como n8n o Make para orquestar flujos, WhatsApp Business API para canal de mensajería, y bases de datos vectoriales cuando se necesita búsqueda semántica sobre documentos. La regla práctica es elegir tecnología establecida y bien documentada para los primeros 90 días — no es momento de experimentar con herramientas en beta.