Cómo implementar inteligencia artificial en una empresa: guía paso a paso

Implementar inteligencia artificial en una empresa no es un proyecto de tecnología: es un proyecto de proceso con un componente de tecnología. Esa distinción parece retórica hasta que ves el embudo real de los proyectos empresariales, y entonces se vuelve la explicación de casi todo lo que sale mal.

Los primeros tres números vienen del mismo estudio y describen un solo embudo. Conviene tratarlos con cuidado: el reporte del proyecto NANDA del MIT Media Lab que los publica es un documento preliminar, no revisado por pares, con una muestra acotada ¹. Pero su forma coincide con lo que reportan firmas que miden de otra manera, y esa convergencia es lo que lo hace útil.

Gartner pronosticó en 2024 que al menos 30% de los proyectos de IA generativa serían abandonados después de la prueba de concepto antes de terminar 2025; en enero de 2026 actualizó esa cifra al alza ³. Para los proyectos agénticos su previsión es que más del 40% se cancele para finales de 2027, por costos crecientes, valor de negocio poco claro o controles de riesgo inadecuados ². Son pronósticos de una firma de análisis, no mediciones de campo, y hay que leerlos como tales; aun así, las tres causas que enumeran son exactamente las que aparecen en los proyectos que heredamos a medio morir.

Hay un segundo patrón, más económico que técnico. En el mismo estudio, cuando se pidió a ejecutivos repartir cien dólares hipotéticos entre funciones, ventas y marketing se llevó alrededor de la mitad del presupuesto ¹, y ese suele ser el terreno donde la IA se ve más, no donde más rinde. El retorno tiende a aparecer en las funciones aburridas: back office, documentos, conciliaciones, soporte.

El primer error es empezar preguntando *¿qué modelo usamos?*. La pregunta correcta es *¿qué proceso nos cuesta más caro y se repite más?*. Un buen candidato tiene cuatro rasgos: ocurre muchas veces al mes, sigue reglas que alguien puede explicar en voz alta, produce o consume texto o documentos, y hoy lo hace una persona que preferiría estar haciendo otra cosa.

McKinsey describe bien la trampa del atajo: cerca de ocho de cada diez empresas han desplegado IA generativa de alguna forma, pero aproximadamente la misma proporción no reporta impacto material en las utilidades. Su explicación es un desbalance entre casos de uso horizontales (copilotos y chatbots de alcance general, que escalan rápido y entregan poco) y casos verticales, específicos de una función, que entregan más pero se quedan atorados en piloto ⁸. Empezar por un copiloto general es la forma más rápida de tener adopción alta y cero impacto medible.

La recomendación práctica: elige un caso vertical con dueño claro, y deja el copiloto general para después, cuando ya tengas una victoria que justifique el presupuesto.

Este paso es el que más proyectos mata y el que más se salta. Gartner predice que hasta 2026 las organizaciones abandonarán 60% de los proyectos de IA que no estén respaldados por datos listos para IA, y en su encuesta a 1,203 líderes de gestión de datos, 63% de las organizaciones no cuenta con las prácticas adecuadas, o no sabe si cuenta con ellas ⁴. Ese *o no sabe* es la parte reveladora.

La auditoría no tiene que ser un proyecto de seis meses. En una semana se puede responder lo esencial: ¿dónde vive el dato, quién puede exportarlo, está completo, tiene historia suficiente, y hay permisos para usarlo? Si la respuesta a cualquiera de esas es *tendría que preguntar*, ese es el primer entregable del proyecto, no un supuesto.

• El dato existe fuera de la cabeza de una persona y fuera de un PDF escaneado sin texto.
• Alguien tiene permiso técnico y legal para exportarlo a donde correrá el sistema.
• Hay suficiente historia para saber cómo se ve un caso normal y uno raro.
• Los campos que importan están poblados en la mayoría de los registros, no en el 30%.
• Sabes qué información es sensible y qué no puede salir de tu infraestructura.

Un prototipo no es un demo. Un demo se construye con datos elegidos para que funcione; un prototipo se construye con tus datos reales, incluyendo los feos, y con un usuario piloto usándolo a diario. Tres semanas es un plazo realista para un caso acotado, y es corto por diseño: el objetivo es descubrir rápido si la idea no sirve.

1. 1

   Semana 1: Conexión y línea base

   Ingesta del dato real, permisos y, lo más crítico, medir cómo se hace hoy. Cuánto tarda, cuánto cuesta, cuántos errores tiene. Sin esta medición previa no vas a poder demostrar mejora después, y ese es el momento en que los proyectos pierden su presupuesto.

2. 2

   Semana 2: Primera versión end-to-end

   El flujo completo funcionando, aunque cada pieza sea imperfecta. Es mejor un recorrido entero mediocre que una sola etapa excelente: los problemas de integración aparecen en las costuras, no en el centro.

3. 3

   Semana 3: Uso real y decisión

   Un usuario piloto lo usa en su trabajo diario y anota dónde falla. Al final de la semana se toma una decisión explícita: seguir, ajustar el alcance, o parar. Parar aquí es barato y es un resultado legítimo.

Aquí es donde el 20% se convierte en 5% ¹. Producción significa cosas concretas y poco glamorosas: observabilidad de latencia, costo y calidad; reintentos cuando el proveedor falla; control de gasto con alertas; versionado de prompts para poder revertir; y una ruta de escalamiento a un humano cuando el sistema no está seguro. Un sistema sin fallback humano no es más autónomo: es más frágil.

También significa integrarse a las herramientas que tu equipo ya abre cada mañana. Si el sistema vive en una pestaña aparte que hay que recordar visitar, la adopción cae sola en cuestión de semanas, sin importar qué tan bueno sea el modelo detrás.

La gobernanza suele llegar tarde y de golpe. Gartner predice que para 2027 el 40% de las empresas degradará o dará de baja agentes autónomos por brechas de gobernanza detectadas solo después de incidentes en producción, y señala la causa de fondo: tratar la gobernanza como algo binario (o todo bloqueado, o plenamente confiable) en lugar de graduarla según el riesgo de cada acción ⁵.

No hace falta inventar el marco. Hay tres referencias que cubren la mayoría de los casos: el AI Risk Management Framework del NIST, voluntario, que organiza el trabajo en cuatro funciones (gobernar, mapear, medir y gestionar) ¹⁰; la norma ISO/IEC 42001:2023, primera norma internacional de sistemas de gestión de IA, certificable por organismos independientes ¹¹; y, si tocas el mercado europeo, el Reglamento de IA de la Unión Europea, en vigor desde agosto de 2024 y aplicable desde el 2 de agosto de 2026, con obligaciones escalonadas que empezaron en febrero de 2025 ¹².

Para una empresa mediana mexicana sin exposición europea, lo mínimo razonable es: registro de cada acción que el sistema ejecuta, control de quién puede pedirle qué, una política escrita sobre qué datos entran al modelo, y un responsable con nombre. Eso ya te pone por delante de la mayoría.

El último paso es el que separa a los proyectos que aparecen en el estado de resultados de los que no. BCG encontró en 2024 que solo 26% de las empresas había desarrollado las capacidades necesarias para ir más allá de las pruebas de concepto y generar valor tangible, y que apenas 4% tenía capacidades avanzadas ⁶. Su recomendación de asignación de esfuerzo es una regla prescriptiva, no una medición, pero resume bien la lección: 10% en algoritmos, 20% en tecnología y datos, 70% en personas y procesos ⁷.

Escalar bien significa cambiar cómo se hace el trabajo alrededor del sistema: quién revisa qué, qué pasos desaparecen, cómo cambian las metas del equipo. Copiar el mismo agente a cinco departamentos sin tocar sus procesos produce cinco pilotos, no una transformación.

Y conviene mantener la ambición calibrada. En la encuesta global de McKinsey de 2025, 88% de los encuestados dice que su organización usa IA de forma regular en al menos una función, pero solo 39% atribuye algún impacto en EBIT a nivel de empresa, y la mayoría de ellos lo ubica por debajo del 5% ¹³. Llegar a ese 39% con un impacto medible y defendible ya es un resultado bueno.