Errores comunes al implementar IA en empresas peruanas y cómo evitarlos

Una revisión operativa, con contexto peruano

AI & Boards 2026 de EY Perú encuestó virtualmente a 250 miembros de directorios, accionistas y altos ejecutivos vinculados a siete sectores, entre el 12 de enero y el 5 de marzo de 2026. Identifica brechas de conocimiento y gobierno; no representa a todas las empresas ni a las MYPE. [1] Los siguientes errores son preguntas de diagnóstico para tu operación, no acusaciones sobre compañías concretas.

Para cada uno, busca una señal observable, estima el costo y verifica la corrección con evidencia. Una explicación convincente del asistente tampoco demuestra que el proceso haya mejorado.

1. Empezar por la herramienta y dejar el problema abierto

Una licencia puede abrir posibilidades, pero el equipo necesita saber qué resultado debe entregar. NIST propone identificar contexto y medir riesgos durante el ciclo del sistema. [2]

• Señal: cada persona describe un objetivo diferente para el piloto.
• Costo: trabajo disperso y resultados imposibles de comparar.
• Corrección: elige una tarea, un responsable y la definición de resultado aceptado.
• Evidencia: casos iniciales con tiempos, errores y criterios de aceptación documentados.

2. Conectar datos sin resolver su significado

El CRM puede usar un código de cliente diferente al del ERP. Pedirle al modelo que adivine esa relación deja una decisión de negocio sin validar.

• Señal: aparecen precios distintos o un cliente tiene varias identidades.
• Costo: cotizaciones erróneas, duplicados y correcciones manuales.
• Corrección: fija identificadores, moneda, impuestos, vigencia y fuente autorizada.
• Evidencia: una muestra conciliada con resultados esperados y un responsable de actualización.

3. Enviar información sensible sin revisar el tratamiento

Una instrucción que diga “no reveles datos” no sustituye restricciones de acceso ni condiciones del proveedor. OWASP identifica la divulgación de información sensible como un riesgo de estas aplicaciones. [4]

• Señal: se cargan archivos completos de clientes desde cuentas personales.
• Costo: exposición de información y pérdida de control sobre su tratamiento.
• Corrección: minimiza los datos y revisa finalidad, autorizaciones, proveedor y conservación.
• Evidencia: inventario de datos enviados, accesos y condiciones aprobadas.

4. Dar permiso para actuar antes de controlar las acciones

La autorización debe aplicarla el sistema que ejecuta. OWASP recomienda limitar funciones, permisos y autonomía; las acciones de alto impacto necesitan aprobación humana. [3]

• Señal: el asistente puede modificar registros ajenos o escribir sin confirmación.
• Costo: operaciones incorrectas o duplicadas al reintentar.
• Corrección: empieza con lectura, limita acciones y vincula aprobación con operación concreta.
• Evidencia: pruebas de rechazo por rol y un reintento que no produzca un segundo efecto.

5. Evaluar solamente ejemplos que salen bien

Una respuesta fluida puede omitir información o inventarla. El perfil de NIST orienta la gestión de riesgos de IA generativa. [2] Lleva esa revisión a pruebas de tu proceso.

• Señal: la demostración evita consultas ambiguas y documentos desactualizados.
• Costo: errores que llegan al cliente o consumen revisión adicional.
• Corrección: prepara casos normales, difíciles y prohibidos, con respuestas esperadas independientes.
• Evidencia: resultados versionados, incluido cuándo el sistema debe abstenerse o derivar.

6. Capacitar en botones y olvidar el trabajo real

El equipo necesita practicar cómo detectar errores, proteger datos y pedir ayuda. Las brechas de conocimiento observadas por EY dan contexto a esa preparación. [1]

• Señal: las personas aceptan todo o rehacen cada respuesta desde cero.
• Costo: retrabajo, uso informal y excepciones sin resolver.
• Corrección: ensaya tareas del puesto, revisión y derivación a un responsable.
• Evidencia: usuarios que reconocen un resultado incorrecto y aplican la ruta de corrección.

7. Contar conversaciones y olvidar el resultado económico

El uso indica actividad. Para decidir si ampliar, compara casos resueltos de dificultad semejante e incluye el esfuerzo humano.

• Señal: hay muchas consultas, pero nadie conoce el costo de resolver una solicitud.
• Costo: gasto creciente y beneficios sin comprobar.
• Corrección: cuenta integración, licencias, consumo, revisión, soporte y retrabajo.
• Evidencia: tiempo total, errores y costo por caso aceptado frente al proceso inicial.

Cómo elegir la primera corrección

Prioriza por consecuencias. Si el sistema expone información o ejecuta cambios sin autorización, restringe esas funciones primero. Si el problema es una fuente errónea, corrige los datos antes de ajustar instrucciones. Si nadie puede demostrar valor, acota el piloto y establece una base de comparación.

Checklist antes de ampliar el uso

• Tarea, responsable y resultado aceptado definidos.
• Fuentes vigentes, identificadores conciliados y permisos revisados.
• Pruebas de errores, acceso indebido y derivación humana aprobadas.
• Costo completo, soporte y retorno al proceso anterior entendidos.
• Retroalimentación registrada y reevaluación tras cambios.

En Perú, revisa el marco de la Ley N.º 31814 y su reglamento, junto con la Ley N.º 29733 y su reglamento de protección de datos. La aplicación de obligaciones exige considerar el caso y los plazos correspondientes. [5] [6]

Si utilizas Dova para preparar datos, su recorrido documentado de Mapping, Session, Workflow y Monitor permite verificar una ejecución de integración. [7] Contrasta la salida con resultados esperados. Esa base no reemplaza la evaluación del asistente ni garantiza retorno económico.