Desarrollo de aplicaciones LLM a medida

Sistemas LLM para producción basados en sus datos

Creamos soluciones de recuperación, flujos asistidos por herramientas y aplicaciones de IA concretas con criterios explícitos de calidad, coste y revisión. El modelo es una parte del sistema, no el producto por sí solo.

  • Evaluación antes del despliegue
  • Recuperación según permisos
  • Revisión humana cuando un error importa
Entorno de evaluación Candidato a lanzamiento
«¿Qué condiciones contractuales se aplican a esta renovación y dónde están documentadas?»
01 · Alcance Política de acceso
02 · Fuentes Contenido aprobado
03 · Acción Modelo + herramientas
04 · Verificación Respuesta + citas
Fundamentación
Obligatoria
Permisos
Solo lectura
Revisión
Responsable definido
Un sistema LLM útil controla fuentes, permisos y rutas de fallo, no solo el prompt.

Empezar por la decisión

Un LLM solo aporta valor cuando el problema lo necesita

Primero comprobamos si la ambigüedad del lenguaje, el conocimiento disperso o la coordinación entre sistemas son el verdadero cuello de botella. Un flujo determinista suele ser más económico y fiable.

Si un LLM no aporta un valor medible, lo indicamos antes de consumir presupuesto en un piloto.

Buen encaje

  • El conocimiento está dispersoLas respuestas dependen de varios documentos, sistemas o niveles de permiso.
  • Las entradas no están estructuradasLas personas trabajan con tickets, contratos, correos o solicitudes abiertas.
  • El criterio puede acotarseUn revisor, una regla o una cita puede detectar errores relevantes.

Conviene un sistema más sencillo

  • La regla ya es explícitaUn servicio, una consulta o un motor de reglas puede producir el resultado correcto.
  • No existe una fuente fiableEl sistema no puede ser más fiable que los datos que recibe.
  • El fallo no se puede revisarLas decisiones autónomas de alto impacto requieren controles más fuertes que una respuesta del modelo.

Decisiones de arquitectura

Aplicar el enfoque más pequeño que resuelva la tarea

«A medida» rara vez significa entrenar un modelo fundacional desde cero. La solución adecuada puede ser automatización convencional, recuperación, uso controlado de herramientas o fine-tuning específico.

Entrada validada Regla de negocio Acción del sistema

Sin modelo

El trabajo predecible debe seguir siéndolo

Las reglas, plantillas y APIs son mejores cuando la entrada y el resultado esperado ya están estructurados.

Utilizar cuando
La misma entrada siempre debe producir el mismo resultado.
Evitar cuando
Es necesario interpretar significado en textos largos o inconsistentes.
Control principal
Validación, contratos tipados y pruebas automatizadas.

Sistemas de ejemplo

Procesos concretos con una ruta de fallo visible

Son patrones de solución, no casos de éxito inventados. Cada uno parte de una tarea acotada y muestra el punto de control.

  1. 01
    Soporte

    Copiloto de soporte con fuentes

    Prepara una respuesta con documentación, contexto del cliente e incidencias conocidas sin mostrar contenido al que el agente no puede acceder.

    Entrada
    Ticket, derechos del cliente e historial de conversación
    Sistema
    Recuperación según permisos y valoración de fuentes
    Salida
    Respuesta sugerida, citas e indicadores de incertidumbre
    Punto de control
    Un agente de soporte edita y envía la respuesta
  2. 02
    Documentos

    Entrada de contratos con gestión de excepciones

    Extrae términos, los compara con la política y deriva cláusulas ambiguas en lugar de imponer una respuesta segura.

    Entrada
    Contrato, política interna y tipo de documento
    Sistema
    Extracción estructurada y validación determinista
    Salida
    Campos, ubicaciones de origen y excepciones pendientes
    Punto de control
    Un responsable resuelve las cláusulas marcadas
  3. 03
    Operaciones internas

    Asistente de conocimiento con acciones gobernadas

    Responde preguntas operativas y prepara una acción aprobada sin dar al modelo acceso de escritura ilimitado.

    Entrada
    Solicitud, rol del usuario y estado actual del sistema
    Sistema
    Recuperación, selección de herramientas y aplicación de políticas
    Salida
    Respuesta citada o vista previa de la acción propuesta
    Punto de control
    Los cambios sensibles requieren confirmación expresa

Calidad antes del lanzamiento

Definir la aceptación antes de crear la interfaz

Un conjunto de evaluación representativo convierte «las respuestas parecen buenas» en una decisión trazable. También descubre regresiones al cambiar prompts, fuentes o proveedores.

Cada fila muestra qué se mide y por qué importa.

MedidaPreguntaEvidencia para lanzar
Calidad de tarea¿Completa correctamente la tarea acotada?Ejemplos revisados con una rúbrica acordada
Fundamentación¿Se pueden rastrear las afirmaciones relevantes hasta fuentes aprobadas?Cobertura de citas y revisión de afirmaciones sin respaldo
Gestión de fallos¿La incertidumbre activa la alternativa correcta?Casos conocidos, pruebas de escalado y rechazo
Operación¿La respuesta es suficientemente rápida y económica a volumen real?Distribución de latencia y coste por tarea completada

Datos y operación

La responsabilidad forma parte del diseño

El hosting y el proveedor pueden variar. La claridad sobre acceso, retención, cambios del modelo y responsabilidad operativa no debe variar.

El modelo operativo permanece explícito con cualquier opción de despliegue.

ÁreaDecisión de diseñoEvidencia operativa
Acceso a datos¿Qué fuentes y registros puede recuperar cada rol?Pruebas de permisos y registros de acceso
Retención¿Qué pueden almacenar proveedores, logs y evaluaciones?Flujo de datos y política de retención documentados
Cambios del modelo¿Quién aprueba un prompt, modelo o estrategia de recuperación?Versiones y resultados de regresión
Incidentes¿Cómo se contiene e investiga una respuesta incorrecta?Desactivación, trazas, responsable y runbook

La ubicación de datos, los derechos del modelo y las condiciones del proveedor se documentan para la arquitectura elegida, no se prometen en abstracto.

Modelo de entrega

De un proceso a un sistema operado

Reducimos la incertidumbre en orden. El primer hito es un recorrido vertical medido, no una plataforma de IA general.

  1. 01

    Acotar la decisión

    Definir proceso, referencia, riesgo, responsable y alternativas más simples.

  2. 02

    Preparar la evidencia

    Reunir ejemplos representativos, permisos de fuentes y criterios de aceptación.

  3. 03

    Construir el recorrido vertical

    Conectar solo los datos y herramientas necesarios para probar el camino completo.

  4. 04

    Evaluar y operar

    Medir calidad, coste y latencia; añadir monitorización, revisión y reversión.

Preguntas prácticas

Lo que los equipos suelen necesitar aclarar

La respuesta depende del proceso y del riesgo, pero la decisión debe ser explícita antes de implementar.

¿Necesitamos entrenar nuestro propio modelo?

Normalmente no. Primero probamos un modelo fundacional adecuado con recuperación, herramientas y controles de aplicación. Solo consideramos fine-tuning cuando la evidencia muestra una carencia estable.

¿Puede funcionar en nuestra infraestructura?

Depende del modelo y de los requisitos operativos. Comparamos APIs gestionadas, nube privada y self-hosting según límites de datos, coste, latencia y mantenimiento.

¿Cuánto tarda un piloto?

Un proceso acotado suele poder evaluarse en varias semanas si existen fuentes, responsables y ejemplos de revisión. Confirmamos el alcance tras comprender los datos y la integración.

¿Cómo reducen las alucinaciones?

Acotamos la tarea, fundamentamos respuestas en fuentes aprobadas, exigimos citas cuando procede y diseñamos alternativas para la incertidumbre. La evaluación mide los fallos restantes; ningún control hace infalible al modelo.

¿Quién posee los datos y la implementación?

Sus datos siguen siendo suyos. Los derechos sobre código, prompts, evaluaciones, pesos ajustados y modelos de terceros se documentan para la tecnología y el contrato elegidos.