Portafolio / Caso de estudio

Caso de estudio · IA legal y de salud

Un asistente de IA es tan bueno como lo que lee.
Nosotros construimos lo que lee.

Una plataforma de IA para abogados y clínicos necesitaba los expedientes de cada práctica: clientes y pacientes, casos, notas, resultados de pruebas. Vivían en sistemas que nunca se diseñaron para hablar entre sí, y menos con una IA. Construimos la capa que los trae, los vuelve consistentes y los hace seguros para actuar con ellos.

Dominios

Legal + salud

Sistemas de gestión de casos, de prácticas, de expedientes clínicos y de bienestar, cada uno con su propia idea de un contacto, una nota o un resultado.

Además de datos de CRM.

Protocolos

REST · SOAP

JSON y XML, OAuth2, claves de API y webhooks, cada uno detrás de su propio adaptador.

El resto de la plataforma nunca necesita saber de qué sistema vino un registro.

Modelo de datos

Uno

Un solo modelo tipado y validado para prácticas, personas, notas y resultados, verificado al entrar.

Un registro mal formado falla de forma visible en lugar de contaminar en silencio el contexto del asistente.

Cliente, producto, sistemas y proveedores reservados, y sin cifras del cliente. Nuestra parte fue la capa de integración y de datos. El asistente, sus agentes, la orquestación, la búsqueda y la recuperación eran del equipo de la plataforma, y trabajamos dentro de ellos.

Cómo lo construimos

Cinco etapas,
las mismas en cada proyecto.

Ingesta

Traer los datos reales, desde donde trabajan las prácticas

El reto

  • Cada práctica guardaba sus expedientes en un sistema distinto
  • Cada sistema hablaba su propio dialecto: REST aquí, SOAP y XML allá
  • La autenticación cambiaba en cada uno: OAuth2, claves de API, webhooks

Lo que hicimos

  • Un adaptador por sistema de origen, que maneja su autenticación, su paginación y sus rarezas, y nada más
  • Ingesta de contactos, casos, pacientes, notas y resultados de pruebas
  • Cada llamada registrada con un identificador de correlación

El punto de partida fueron los expedientes reales de cada práctica, no un conjunto de datos de demostración.

Normalización

Que registros incompatibles signifiquen lo mismo

El reto

  • Un “contacto”, una “nota” o un “resultado” significaba algo distinto en cada sistema
  • Identificadores, formatos, fechas y terminología no coincidían
  • Los datos malos habrían llegado al asistente sin que nadie lo notara

Lo que hicimos

  • Un solo modelo tipado y validado para cada tipo de registro, aplicado en la frontera
  • Resolvedores que traducen los campos e identificadores de cada fuente a ese modelo
  • Los registros que no encajan se rechazan y se registran, nunca se pasan

Una IA sofisticada sobre contexto poco confiable sigue dando respuestas poco confiables. En esta capa es donde se evita.

Confianza

Que los datos sean seguros para actuar

El reto

  • Los expedientes legales y de salud están entre los datos más sensibles que existen
  • Una llamada exitosa a una API no equivale a datos correctos
  • Los equipos que dependían de los datos necesitaban poder confiar en cada registro

Lo que hicimos

  • Validación al entrar, y errores estructurados cuando algo está mal
  • Control de acceso, manejo de credenciales y separación entre prácticas
  • Pruebas de punta a punta en todos los caminos de integración

Un HTTP 200 no significa que el resultado sea confiable. Las verificaciones sí.

Valor

Darle al asistente contexto del que valga la pena responder

El reto

  • Las respuestas del asistente dependen de la calidad de lo que recupera
  • Los profesionales actúan según lo que el asistente les dice

Lo que hicimos

  • Expedientes limpios, consistentes y al día, entregados en una sola forma a la búsqueda, la recuperación y los agentes de la plataforma

La meta nunca fue “conectarse a todo”. Fueron respuestas en las que un abogado o un clínico pueda confiar.

Producción

Que siga funcionando cuando el otro lado falla

El reto

  • Los sistemas externos limitan peticiones, se demoran, cambian sin aviso y devuelven datos inconsistentes

Lo que hicimos

  • Reintentos y tiempos límite en cada llamada
  • Patrones de circuit breaker y límites de peticiones, para que una fuente caída no tumbe a las demás
  • Registros estructurados para seguir cualquier registro desde la fuente hasta el asistente

Construido para el día en que una fuente falle, porque ese día siempre llega.

Quién hizo qué

Nuestra parte,
dicha con exactitud.

La plataforma

Un producto más amplio, una capa clara.

CapaQué haceA cargo de
IntegracionesSe conecta con los sistemas legales, de salud, de bienestar y de CRM de cada prácticaEVDevs
Ingesta y normalizaciónTrae los expedientes y los convierte en un solo modelo validadoEVDevs
ConfiabilidadReintentos, circuit breakers, límites de peticiones, registros trazablesEVDevs
Búsqueda y recuperaciónEncuentra el contexto correcto para cada preguntaEquipo de la plataforma
Asistente y agentesResponde a los profesionales y orquesta el trabajoEquipo de la plataforma

Todo lo que está encima de la capa de datos depende de ella. Por eso la tratamos como los cimientos, no como tuberías.

Lo que demuestra

La IA confiable empieza
debajo del modelo.

Fallas

Contenidas

Una fuente lenta o caída no puede tumbar a las demás.

Reintentos, tiempos límite, circuit breakers y límites de peticiones en cada llamada.

Trazabilidad

De punta a punta

Cualquier registro se puede seguir desde su sistema de origen hasta el contexto del asistente.

Registros estructurados con identificadores de correlación.

Datos sensibles

Por diseño

Control de acceso, manejo de credenciales y separación entre prácticas fueron requisitos de ingeniería, no trámites.

Construido según las expectativas de HIPAA, SOC 2 y GDPR.

Cómo trabajamos

  1. Empezar por los datos reales

    Trabajamos con los sistemas donde de verdad opera el negocio, no con una muestra limpia.

  2. Normalizar antes de modelar

    Una sola forma validada para cada registro, para que la IA nunca tenga que adivinar qué significa un campo.

  3. Verificar, no suponer

    Validación, pruebas y registros trazables, porque una petición exitosa no es una respuesta correcta.

  4. Construir para la falla

    Todo sistema externo va a fallar algún día; la plataforma tiene que seguir funcionando cuando pase.

¿Construyendo IA sobre datos
en los que aún no confías del todo?

Cuéntanos dónde viven tus datos y qué necesita responder tu IA. Te diremos qué hace falta para que esos datos sean confiables, y cuál podría ser el siguiente paso práctico.

¿Prefieres escribirnos directamente? activa JavaScript para ver la dirección

Habla con un ingeniero

Sin teatro comercial. Cuéntanos dónde tu operación se siente lenta, repetitiva o difícil — un ingeniero lee cada mensaje.

Tu mensaje llega directamente a nuestros ingenieros en nuestra dirección.