Implementar IA en empresas en Perú: qué cambia respecto al manual global

El consultor trajo el mapa de una corporación y la empresa no tenía el territorio que ese mapa asumía

La reunión de kickoff fue impecable. Slides con el logo de una consultora internacional, casos de una cadena retail estadounidense con miles de tiendas, un cronograma a dieciocho meses con hitos trimestrales y un equipo de datos de seis personas a tiempo completo. La gerencia salió de esa sala convencida de que por fin la empresa iba a “hacer IA en serio”. Nadie preguntó, en ese momento, si la empresa tenía lo que ese plan daba por sentado.

La primera señal llegó a la tercera semana, cuando el equipo del consultor pidió acceso al “data warehouse” para empezar el diagnóstico. No existía. Lo que existía eran seis hojas de cálculo administradas por tres personas distintas, con nombres de columna que no coincidían entre sí y un historial real de apenas dos años, porque antes de eso la empresa llevaba buena parte de sus cuentas a mano. La segunda señal llegó cuando preguntaron quién sería el “data owner” del lado de la empresa: la respuesta fue una gerente de operaciones que ya trabajaba diez horas al día y para quien este proyecto era, en la práctica, un encargo más sin tiempo asignado.

A los tres meses el proyecto seguía en fase de “levantamiento de información”, el presupuesto trimestral aprobado ya se había gastado en horas de consultoría sin un solo modelo corriendo, y el sponsor interno empezó a recibir la pregunta incómoda de su directorio: ¿qué compramos exactamente? El plan no fracasó porque el método fuera malo. Fracasó porque nadie lo adaptó a lo que la empresa realmente tenía: datos recientes y dispersos, una sola persona sosteniendo el proyecto además de su trabajo de siempre, y un presupuesto que se revisa cada tres meses, no cada dieciocho.

Lo que en verdad cambia no es el método, son tres condiciones de partida

El método detrás de cualquier implementación seria de inteligencia artificial es el mismo en Lima que en Boston: diagnosticar el proceso que duele, elegir un piloto medible dentro de un roadmap de inteligencia artificial pensado a doce meses, correrlo, medir el resultado contra un número de partida y recién ahí decidir si se escala. Ese orden es, en esencia, el framework Arquitectura IA aplicado sin atajos, y no cambia porque cambie el país. Lo que sí cambia, y es lo que el consultor de la escena anterior no ajustó, son las condiciones con las que ese método tiene que trabajar en la práctica.

Esas tres condiciones no son un matiz cultural, son restricciones de diseño. El estado de los datos define qué tan rápido se puede empezar a medir algo real. La disponibilidad de talento define si el proyecto se puede sostener con gente propia o depende de un tercero todo el tiempo. Y el tamaño de proyecto que la empresa puede pagar y terminar define el alcance correcto para el primer piloto, no el que aparece en el caso de estudio importado. Las siguientes secciones desarrollan cada una de estas tres condiciones, y las que vienen después cubren lo normativo, lo comercial y lo sectorial.

El estado típico de los datos en la empresa mediana peruana no es el que asume el caso de estudio importado

Cuando reviso el estado de datos de una empresa mediana peruana antes de proponer cualquier proyecto de inteligencia artificial, encuentro casi siempre el mismo patrón, más allá del rubro. No es un patrón malo ni vergonzoso: es el patrón normal de una empresa que creció rápido, formalizó procesos sobre la marcha y nunca tuvo, hasta hace poco, una razón de negocio para ordenar sus datos con disciplina. El error no es tener ese estado de partida. El error es diseñar un proyecto de IA como si ese estado de partida no existiera.

• Datos dispersos en hojas de cálculo y sistemas que no conversan entre sí: ventas en un ERP, cobranzas en otro sistema, atención al cliente en un tercero, y nadie cruza los tres de forma sistemática.
• Historial corto: buena parte de la empresa mediana peruana formalizó sus procesos hace pocos años, así que el histórico limpio y confiable suele cubrir dos o tres años, no la década que asume un caso de estudio de una corporación centenaria.
• Ausencia de un dueño del dato: la información existe, pero nadie tiene como parte formal de su puesto mantenerla ordenada, así que se degrada cada vez que alguien renuncia o cambia de área.
• Reglas de negocio que viven en la cabeza de una persona, no en un sistema: el criterio real de por qué se aprueba o rechaza algo está en la experiencia de quien decide, no documentado en ninguna parte.

Ninguno de estos puntos descalifica a la empresa para hacer IA. Los descalifica para copiar un proyecto de dieciocho meses pensado para un histórico de diez años y un equipo de datos dedicado. La consecuencia práctica es que buena parte del primer proyecto de IA en una empresa peruana mediana es, en realidad, un proyecto de orden de datos con un piloto de IA al final, no al revés. Quien vende el piloto sin mencionar el orden previo está vendiendo la parte fácil y escondiendo la que de verdad toma tiempo.

Sí hay talento de IA en Perú, pero no en la cantidad ni en el precio que asume el manual global

La primera pregunta que me hacen cuando explico que el proyecto necesita ajustarse al talento disponible es si en Perú hay gente capaz de sostenerlo. La respuesta corta es sí, y la respuesta completa tiene matices que importan más que el sí o el no. Hay talento real, concentrado sobre todo en Lima, con experiencia genuina construyendo e implementando modelos y agentes en producción, no solo probándolos en una demo. Ese talento es escaso en proporción a la demanda que generó el auge de la IA generativa, y eso se nota en cómo se cotiza.

También hay, y esto lo digo como observación propia de lo que veo en el mercado, no como estudio, una capa mucho más ancha de gente que se presenta como “especialista en IA” después de un curso corto o de usar herramientas de prompt durante unos meses. Esa capa cobra menos, pero entrega menos: sabe operar una herramienta, no diseñar ni sostener un sistema en producción. Confundir a alguien que sabe usar bien una herramienta con alguien que sabe construir e integrar un sistema es el error de contratación más caro que veo repetirse, porque el primer perfil no puede sostener el segundo tipo de proyecto.

En precio, lo que observo, otra vez con mirada de mercado y no de estudio, es que un perfil senior capaz de llevar un modelo o un agente a producción y mantenerlo cuesta sensiblemente menos en Lima que su equivalente remoto en Estados Unidos o Europa, pero no cuesta poco, porque son pocos y están repartidos entre pocas empresas que ya entendieron su valor. La brecha real no está en el precio, está en que la mayoría de empresas todavía no sabe distinguir, en una entrevista o en una propuesta comercial, entre el perfil que opera una herramienta y el que construye el sistema detrás.

El marco normativo que aplica no es un capítulo aparte, es la Ley de Protección de Datos Personales tocando lo primero que la IA toca

En Perú, cualquier proyecto de inteligencia artificial que use datos de clientes, prospectos o empleados, que es la enorme mayoría de los proyectos con valor de negocio real, opera bajo el marco de la Ley de Protección de Datos Personales peruana. No hace falta memorizar articulado para tomar buenas decisiones de diseño: hace falta tratar esa ley como una restricción de arquitectura desde el primer día, no como un trámite legal que se revisa al final, cuando ya se subieron datos de clientes a una herramienta de un tercero.

En la práctica, lo que esto exige antes de escribir la primera línea de un proyecto es simple de enunciar y fácil de saltarse bajo presión de plazo: saber para qué se recolectó cada dato y si ese uso encaja con el propósito original, saber si el dato sale del país al subirlo a un servicio en la nube y bajo qué condición, y saber quién dentro de la empresa responde si algo sale mal. Ninguna de esas tres preguntas depende de qué tan sofisticado sea el modelo. Depende de que alguien las haya hecho antes de conectar el primer dato real, y en la prisa por “tener ya una IA” es exactamente lo que se salta.

Vale la pena separar dos cosas que se mezclan seguido: cumplir con la ley de protección de datos y tener un marco de gobierno de IA. Lo primero es un piso legal que aplica sí o sí. Lo segundo (definir quién aprueba qué, qué controles existen, quién responde por un error de un modelo) es una decisión de madurez que toda empresa debería tomar antes de escalar, no solo la que ya tuvo un incidente. Conviene revisar en detalle qué normativas regulan el uso de IA en empresas más allá de la protección de datos, porque el marco legal alrededor de la IA sigue moviéndose y no se agota en una sola ley.

Por qué el proyecto tiene que ser más chico y mucho más rápido que en el caso de estudio importado

El tercer eje que cambia es el tamaño de proyecto que la empresa puede pagar y, sobre todo, terminar. Un caso de estudio de una corporación global suele describir un programa a dieciocho o veinticuatro meses, con presupuesto aprobado de forma plurianual y un equipo dedicado que no cambia de foco aunque cambie el trimestre. Esa estructura casi no existe en la empresa mediana peruana, donde el presupuesto se revisa cada trimestre, el sponsor del proyecto puede cambiar de puesto o de empresa en el camino, y rara vez hay más de una persona sosteniendo la iniciativa además de su trabajo de siempre.

Diseñar el proyecto del tamaño equivocado no es un error de ambición, es un error de supervivencia del proyecto mismo. Un piloto de seis meses sin resultado visible a las ocho semanas no llega al mes seis: muere la primera vez que alguien pregunta en un comité qué se obtuvo hasta ahora. Por eso el proyecto correcto en este contexto no es una versión reducida del proyecto grande, es un proyecto distinto: una sola decisión repetida y dolorosa, un piloto que entrega una primera señal de resultado en semanas y no en trimestres, y un alcance que una sola persona del lado de la empresa pueda sostener sin declarar dedicación exclusiva.

Esto no es lo mismo que hacer un proyecto pequeño porque el presupuesto es chico. Es elegir deliberadamente el proyecto más chico que puede demostrar valor real, para después escalarlo con presupuesto que ya se ganó el derecho de pedir. La diferencia entre la implementación de IA en una pyme y en una empresa grande no es solo de presupuesto disponible, es de cuánto margen de error tolera la organización antes de que el proyecto pierda apoyo interno, y en la empresa mediana peruana ese margen suele ser mucho más corto de lo que el plan importado asume. Quien quiere ver cómo se arma esto con presupuesto ajustado puede revisar cómo implementar IA con poco presupuesto, que desarrolla el mismo principio de piloto chico y rápido antes de escalar.

Qué proveedores hay en el mercado peruano y cómo evaluarlos sin comprar humo

En el mercado que atiende empresas peruanas conviven, sin orden claro, al menos cuatro tipos de proveedor. Las grandes nubes internacionales, que ofrecen la infraestructura y cada vez más servicios de IA ya empaquetados. Las consultoras internacionales grandes, que traen metodología probada en otros mercados, la misma que hay que ajustar a las tres condiciones de esta página. Las consultoras y boutiques locales especializadas en IA, que suelen conocer mejor el contexto pero varían mucho en profundidad técnica real. Y los freelancers y estudios de desarrollo que “también hacen IA” porque el mercado lo pide, sin que eso sea necesariamente su especialidad.

Más allá de ese criterio general, hay preguntas puntuales que sirven para separar a quien sabe sostener un proyecto de quien solo sabe venderlo: quién queda a cargo de mantener el modelo o el agente después de la entrega, qué pasa cuando el comportamiento del sistema se degrada con el tiempo, y si el proveedor depende de una sola persona clave que podría irse a mitad de proyecto. Para ordenar todo este proceso de selección con más detalle conviene revisar cómo elegir un consultor de IA para tu empresa, que desarrolla los criterios de contratación punto por punto.

Los casos por sector que más pesan en la región, y por qué no se copian tal cual

Sin citar cifras de adopción (ese dato cambia todo el tiempo y casi siempre se cita mal), sí puedo señalar, por lo que veo trabajar en la región, en qué sectores la IA lleva más tiempo dando resultado medible y por qué esos patrones no se trasplantan sin ajuste a una empresa peruana mediana.

• Banca y servicios financieros: scoring de riesgo y detección de fraude, apoyados en años de historial transaccional que ya viene relativamente ordenado por regulación previa. Es el sector con la ventaja de datos más clara de partida.
• Retail y consumo masivo: pronóstico de demanda y precios, donde el reto no es la falta de datos de venta sino cruzarlos con inventario y logística que suelen vivir en sistemas separados.
• Minería y manufactura: mantenimiento predictivo sobre sensores de equipos, un caso fuerte cuando existe telemetría real, y prácticamente inexistente cuando el mantenimiento todavía se registra en cuadernos de planta.
• Agroexportación: control de calidad y logística de exportación, con datos de campo que suelen ser más recientes y más dispersos que los de banca, porque la digitalización del campo llegó después que la del sistema financiero.

El patrón se repite en los cuatro: el sector que tiene más historial ordenado por su propia naturaleza, la banca por regulación, la minería por telemetría de equipo, llega con ventaja real a cualquier proyecto de IA, y el que todavía no lo tiene necesita invertir primero en ordenar antes de pedir el mismo resultado. Copiar el caso de un banco global en una empresa agroexportadora mediana falla por la misma razón que falló el consultor de la primera escena: el caso asume un estado de datos que la empresa que lo copia todavía no construyó.

El criterio final: ajusta el tamaño y el punto de partida, no la lógica del método

Después de revisar los tres ejes (datos, talento y tamaño de proyecto) y el marco que los rodea (norma de protección de datos, tipo de proveedor, patrón por sector) queda una sola decisión de fondo, y es la que de verdad separa al proyecto que sobrevive del que se apaga en el primer comité: elegir el tamaño de piloto que la empresa puede terminar con lo que realmente tiene hoy, no con lo que un caso de estudio de otro país asume que debería tener.

Mi posición no es que la empresa peruana deba conformarse con menos ambición. Es que la ambición correcta empieza más chica de lo que el ego del proyecto quiere, precisamente para poder crecer después con evidencia real en la mano. Un consultor de IA que llega proponiendo el programa de la corporación multinacional sin preguntar primero por el estado de los datos, el talento disponible y el ciclo de presupuesto de la empresa que lo contrata no está adaptando el método: está vendiendo el mismo manual que ya falló una vez, con otro logo en la portada. El método global sigue siendo válido. Lo que hay que tener el criterio de ajustar, antes de firmar el contrato, son las tres condiciones de partida que esta página describió.