55.000 reembolsos al mes dependían de revisión manual. Construimos la capa semántica que permitió automatizarlos con IA.

Una insuretech-fintech chilena de seguros dentales necesitaba escalar su operación de reembolsos sin crecer linealmente en revisores humanos. El desafío parecía ser de OCR y lectura de documentos. No lo era. El verdadero cuello de botella estaba en que cada clínica nombraba los procedimientos a su manera, y sin un lenguaje común, ningún modelo de IA podía operar de forma confiable. Construimos la arquitectura que resolvió eso primero.

Cómo estandarizar datos desordenados es la base para que la IA realmente funcione en producción, y qué cambió cuando lo resolvimos.

La mayoría de los proyectos de IA operacional no fallan por el modelo. Fallan porque el negocio no habla un lenguaje estándar.

Ese problema aparece mucho antes de entrenar cualquier cosa. Aparece cuando distintas clínicas, sucursales o proveedores nombran lo mismo de maneras distintas. Cuando cada documento tiene un formato diferente. Cuando el dato existe, pero nadie acordó realmente qué significa.

Y en operaciones donde una decisión impacta pagos, liquidaciones o reembolsos, no basta con que la IA "más o menos entienda" un documento. La operación necesita consistencia, trazabilidad y reglas claras.

¿Por qué 55.000 solicitudes mensuales no podían automatizarse?

Una insuretech-fintech del sector de seguros dentales en Chile procesaba más de 55.000 solicitudes de reembolso al mes, equivalentes a más de 220.000 archivos. Cada solicitud llegaba con múltiples documentos: formularios, boletas, vouchers, planes de tratamiento, radiografías. Y cada uno tenía que ser leído, validado y clasificado antes de entrar al proceso de liquidación.

La intención de automatizar existía. La tecnología también. Lo que faltaba era el estándar que hacía posible que esa tecnología operará de forma confiable.

El problema de fondo era específico del sector dental: a diferencia del sistema de salud general, que tiene codificación nacional de procedimientos, el sector dental en Chile no tiene estándar. Cada clínica nombra los mismos procedimientos a su manera. "Extracción simple pieza 14", "Exodoncia compleja Pz14", "Extracción molar" son el mismo acto clínico, pero para un sistema automatizado son tres entidades distintas que no se pueden comparar ni clasificar.

Cuando una operación depende de interpretación humana para procesar ese volumen, aparecen síntomas que cualquier gerente de operaciones reconoce al tiro.

Escala lineal en revisión. Más solicitudes requieren más revisores especializados. El volumen crece y el equipo de operaciones crece con él. Eventualmente el modelo deja de ser sostenible (y el CFO empieza a hacer preguntas incómodas).

Inconsistencia operacional. Distintas personas interpretan casos similares de maneras distintas. Aparecen diferencias de criterio, riesgo de doble reembolso y aprobaciones inconsistentes que son difíciles de auditar.

Fricción en la experiencia del asegurado. Cada validación manual agrega tiempo e incertidumbre al proceso de reembolso. El asegurado no sabe por qué demora, solo sabe que demora.

El OCR funcionaba. El modelo clasificaba. Pero la operación seguía necesitando revisión humana caso a caso porque nadie había resuelto el problema más difícil: construir una capa semántica confiable que permitiera confiar en las respuestas.

La decisión estratégica: estandarizar antes de automatizar

La tentación en este tipo de proyectos es ir directo al modelo. Tomar los datos tal como están, entrenar, desplegar, iterar. Es el camino más rápido para llegar a un piloto.

También es el camino más rápido para llegar a un piloto que no pasa a producción.

La decisión estratégica fue otra: antes de construir la automatización, construir la capa que le da lenguaje común a los datos. Un catálogo maestro de prestaciones dentales al que todas las variaciones de nomenclatura pudieran traducirse. Sin esa capa, el modelo aprende ruido. Con ella, aprende a clasificar.

Eso es lo que en la conversación de datos se llama una fundación de datos. En este caso no fue infraestructura abstracta. Fue una decisión concreta de priorización: resolver el problema semántico antes del problema tecnológico.

¿Retrasó el proyecto? Sí. ¿Fue lo que permitió que llegara a producción? También.

Las tres decisiones que definieron el resultado

No fue el modelo lo que hizo que esto funcionara. Fueron tres decisiones de diseño que separaron este proyecto de los pilotos que se quedan en piloto.

Construir el traductor universal antes que el automatizador

El primer paso no fue el OCR ni el modelo de clasificación. Fue el modelo de homologación: entrenado con más de 54.000 registros históricos de liquidación manual del sector, recibe cualquier descripción de procedimiento dental (escrita como la escribió la clínica, con todas sus abreviaturas, errores y creatividad ortográfica) y la traduce al código del catálogo maestro.

Se desarrolló con FastText más diccionarios especializados. El modelo recibía la descripción textual, la edad del paciente y el contexto del procedimiento, y devolvía el código homologado con su score de confianza.

En la práctica, funcionaba como un traductor universal capaz de convertir cientos de nomenclaturas distintas en una estructura estándar utilizable por la operación.

El camino alternativo habría sido entrenar un modelo directamente sobre la variabilidad. Ese modelo aprendería las variaciones, funcionaría en los casos que conoce y fallaría de forma impredecible en los que no. Sin resolver la semántica, la automatización produce errores difíciles de detectar. Y en un proceso de reembolso, un error es un pago incorrecto (un dolorcito de cabeza financiero que nadie quiere tener).

Tratar las alucinaciones de IA como parte del diseño, no como excepciones

Los modelos de OCR basados en LLMs (en este caso Gemini) leen documentos de estructura variable con una generalización que el OCR tradicional no tiene. También alucinan: pueden completar campos ausentes con información plausible pero incorrecta. RUTs inventados, montos que no cuadran, fechas que no existen.

Cuando una decisión impacta pagos reales, automatizar errores es peor que no automatizar nada.

La solución no fue elegir entre IA o reglas. La combinación correcta fue IA más estructura semántica más validación operacional. Se diseñó una capa de coherencia como módulo explícito de la arquitectura: siete reglas de validación por documento antes de que cualquier dato llegue al proceso de negocio. RUTs válidos y distintos entre paciente y empresa. Montos dentro del rango permitido para prestaciones dentales. Fechas sin anomalías. Detección de posibles alucinaciones.

Esta capa no rechaza documentos: los marca. Le dice al sistema qué datos son confiables y cuáles requieren revisión. Diseñarla desde el inicio fue lo que permitió confiar en el sistema en producción.

Definir el umbral de confianza como decisión de negocio, no como parámetro técnico

El modelo no predice con la misma seguridad en todos los casos. La decisión fue no exigirle que cubriera el 100%. En cambio, se diseñó un sistema de umbral: los casos donde el modelo opera con alta confianza se procesan automáticamente; los que quedan bajo el umbral van a revisión humana, pero con la clasificación recomendada ya cargada.

Automatizar bien no significa eliminar criterio. Significa concentrarlo donde realmente importa. El revisor no parte de cero: evalúa una propuesta, aprueba o corrige. El tiempo por caso se reduce. La consistencia mejora porque el modelo propone desde el mismo catálogo estándar en todos los casos.

Esto suena obvio cuando lo lees. En la práctica, la mayoría de los proyectos de IA que hemos visto intentan cubrir el 100% de los casos, se frustran con la precisión, y terminan sin desplegar nada.

¿Qué quedó instalado?

El resultado concreto fue que la empresa dejó de depender exclusivamente de la revisión manual para procesar cada solicitud de reembolso.

El 60% de las solicitudes se procesa de forma automática, sin intervención humana. El sistema lee los documentos, los valida contra las reglas de coherencia, clasifica las prestaciones y entrega la información estructurada al proceso de liquidación.

El 40% restante llega a revisión con la recomendación del modelo ya cargada. El revisor evalúa y aprueba, no investiga desde cero. El tiempo por caso se redujo de forma significativa, y la consistencia operacional mejoró: menos diferencias de criterio entre revisores, menor riesgo de doble reembolso o aprobaciones inconsistentes.

Pero la consecuencia de fondo es la que importa: la operación puede absorber mayor volumen de solicitudes sin que la carga de revisión manual crezca proporcionalmente. La capa semántica (el modelo de homologación, las reglas de coherencia, la lógica de agregación) es la que hace posible que el modelo de IA opere con confianza, y no como una caja negra que produce resultados difíciles de auditar.

Eso es lo que significa que la fundación de datos funcione.

Nuestra recomendación cuando quieres automatizar operaciones con IA

En la mayoría de los proyectos de automatización con IA que hemos visto, el fracaso ocurre antes del modelo. No por falta de tecnología, sino porque nadie resolvió el problema que está debajo: los datos no tienen un lenguaje común sobre el que el modelo pueda operar con confianza.

Estas son las preguntas que determinan si tu proyecto llega a producción o se queda en la demo que nunca escala.

1) Parte por el lenguaje del negocio, no por el modelo

Si distintas fuentes, áreas o proveedores nombran las mismas cosas de forma diferente, el primer proyecto no es de IA: es de estandarización. Mapea la variabilidad, construye el catálogo maestro, entrena el traductor. Sin ese paso, el modelo aprende ruido. Esto no aplica si tu operación ya tiene nomenclatura estándar y datos limpios (felicitaciones, eres la excepción).

2) Valida si tienes registros históricos de la decisión correcta

Un modelo supervisado necesita ejemplos etiquetados. Si tu empresa tiene historia de decisiones manuales (aprobaciones, clasificaciones, liquidaciones), ese es tu dataset de entrenamiento. El entrenamiento del modelo es rápido; tener los datos correctos para entrenarlo es el trabajo real.

3) Define el umbral de automatización antes de construir

Exigirle al modelo que cubra el 100% de los casos es el error más común. El diseño correcto parte de una pregunta honesta: ¿en qué porcentaje de casos el modelo puede operar con alta confianza? Ese es el objetivo real. El resto va a revisión asistida. Definir ese umbral desde el inicio, y diseñar la experiencia del revisor para ese porcentaje, es lo que distingue un piloto de un sistema en producción.

4) Diseña la validación de datos como parte de la arquitectura desde el día uno

Los errores de extracción no se manejan después del despliegue. Se diseñan como una capa explícita desde el principio. Cada dato que entra al proceso de negocio debería pasar por reglas de coherencia que certifiquen su confiabilidad. Especialmente cuando hay IA de por medio y una decisión financiera al final de la cadena.

5) Automatizar bien significa priorizar criterio humano, no eliminarlo

La mejor automatización no saca personas del proceso. Hace que el equipo humano se concentre donde realmente agrega valor: los casos complejos, los bordes, las excepciones que un modelo no puede resolver solo. Si tu proyecto de IA tiene como KPI "eliminar al equipo de revisión", probablemente el proyecto tiene un problema de expectativas antes que uno técnico.

¿Tu operación tiene un patrón similar?

Este caso es del sector de seguros dentales. Pero el patrón aparece en muchas industrias.

Operaciones financieras basadas en documentos heterogéneos. Sistemas que no hablan el mismo idioma. Nomenclaturas inconsistentes entre proveedores, sucursales o canales. Equipos revisando información manualmente porque nadie construyó la capa que permite confiar en la automatización. Procesos que crecen más lento que el negocio porque cada caso nuevo necesita un par de ojos humanos.

Banca, seguros, salud, logística, retail financiero. El problema no es distinto.

Preguntas frecuentes

¿Qué significa construir una capa semántica para IA?

Significa crear una estructura común que permita interpretar información equivalente aunque venga escrita o estructurada de maneras distintas. En la práctica, es el paso que traduce la variabilidad real de los datos de negocio a un lenguaje estándar que un modelo puede consumir con confianza. Sin esa capa, la IA opera sobre ruido y produce resultados inconsistentes.

¿En qué industrias aplica este enfoque de automatización con IA?

El patrón es el mismo en cualquier sector con procesos de alto volumen y sin estándar de nomenclatura: seguros, banca, salud, logística, retail financiero. Lo que varía entre industrias es el catálogo maestro que el modelo aprende a traducir. La arquitectura de extracción, validación, estandarización y umbral de confianza es replicable cuando el problema central es variabilidad semántica en los datos de entrada.

¿Qué es una fundación de datos y por qué importa antes de implementar IA?

Una fundación de datos es el conjunto de capacidades que permiten que los datos sean confiables, consistentes y utilizables: calidad, gobernanza, estándares de nomenclatura, pipelines de validación. Gartner, en una encuesta a 353 líderes globales de datos e IA publicada en abril de 2026, encontró que las organizaciones con iniciativas de IA exitosas invierten hasta cuatro veces más en estas fundaciones que aquellas con malos resultados. Sin esa base, los modelos operan sobre datos ambiguos y producen resultados que no escalan.

¿Cómo se define el umbral de confianza en un modelo de clasificación automática?

El umbral de confianza es el nivel de seguridad a partir del cual el modelo decide de forma autónoma. Por debajo de ese umbral, el caso va a revisión asistida. El diseño correcto analiza los datos de validación del modelo: en qué rango de score la precisión supera el nivel aceptable para el proceso de negocio. No es un parámetro técnico fijo, es una decisión de negocio que equilibra automatización con confiabilidad aceptable en producción.

En Datalized ayudamos a equipos a construir productos de datos que funcionan en operaciones reales y a crear las fundaciones para poder incorporar analítica avanzada e IA.

¿Quieres explorar si tu negocio tiene oportunidades de crecer a partir del aprovechamiento de tus datos? 

Por Natalia Sepúlveda Rosas.Lidera proyectos y analítica en Datalized, convencida de que los datos solo sirven si ayudan a tomar mejores decisiones y a mover la aguja del negocio. Profesora de Tecnologías de la Información para los Negocios en Universidad Diego Portales y especialista en BI y analítica aplicada, lleva más de 10 años haciendo que las cosas pasen en clientes de operaciones complejas. Fanática del kickboxing, de los proyectos que sí llegan logran resultados y de escaparse a Pichilemu cada vez que puede.
Linkedin y otros post de Natalia.