Evidencia — Sistema de referencia
Sistema gobernado de operaciones de casos
Un sistema operativo completo para resolver casos entrantes: recepción estructurada y no estructurada, un flujo de trabajo determinista alrededor de una IA gobernada, autoridad humana condicionada por la consecuencia, y un rastro de auditoría completo. Léalo a través de siete vistas conectadas.
Implementación de referencia
Una implementación de referencia sobre un escenario de casos sintético con datos sintéticos. No es trabajo de un cliente y no describe ninguna organización real.
La interfaz de trabajo
Un caso, tres estados — el mismo flujo gobernado.
Cambie entre estados para ver cómo avanza un caso: evaluación del modelo registrada, una persona con autoridad sobre la decisión consecuente, y cada paso escrito en el rastro de auditoría. Una implementación de referencia sobre datos sintéticos.
CASO CO-2480
Reevaluación de siniestro — póliza 88-4471
- Responsable
- Mesa de siniestros · SLA 2 días
- Evaluación del modelo
- Elegible · confianza 0,86 Elegible · confianza 0,86 Evidencia insuficiente · confianza 0,41
- Fuentes
- póliza §4.2 · informe del evaluador · 12 documentos
- Autoridad
- Decisión de alto impacto — la aprueba una persona
- 14:02:11 evaluación del modelo registrada · fuentes adjuntas
- 14:02:11 enrutado a aprobación humana · alto impacto
- 14:07:52 aprobado por A. Rivas · actuó en ERP y CRM
- 14:09:03 devuelto a la recepción · formulario faltante solicitado
- 13:51:02 excepción EXC-04 · operador notificado
Vista 01 · Ejecutiva
Toda la operación funciona como un solo sistema.
Un caso es una unidad de trabajo única: una solicitud estructurada acompañada de documentos o correspondencia de apoyo. Resolverlo bien significa leer los documentos, aplicar la política, decidir, actuar en los sistemas de registro, y poder mostrar — más tarde — exactamente qué pasó y por qué.
Hecho manualmente a través de herramientas separadas, ese trabajo es lento, inconsistente y difícil de auditar. El Sistema gobernado de operaciones de casos lo convierte en una sola operación determinista: la IA acelera la lectura y redacción rutinarias, los humanos siguen siendo responsables de las decisiones consecuentes, y cada paso se registra.
-
Rendimiento con control
Los pasos rutinarios se ejecutan automáticamente dentro de límites establecidos; las personas dedican su atención al juicio, no al enrutamiento administrativo.
-
Consistencia
La misma política, recuperación y verificaciones se aplican a cada caso, de modo que los resultados no dependen de quién lo haya tomado.
-
Demostrable
Un rastro de auditoría de solo adición registra cada actor, acción, cita y aprobación — para que una decisión pueda explicarse y defenderse.
-
IA segura
El modelo asiste dentro de un límite de control; las acciones consecuentes requieren aprobación humana. La capacidad aumenta sin que la autoridad supere a la consecuencia.
Los resultados anteriores son a nivel de diseño. Este sistema de referencia no reporta rendimiento, precisión ni coste de producción medidos — véase la vista de evaluación.
Vista 02 · Operativa
Cómo avanza un caso.
Cada caso sigue el mismo camino determinista. El flujo de trabajo — no el modelo — decide qué sucede a continuación; la IA realiza su trabajo dentro de un estado, y los casos consecuentes se detienen para un humano.
Máquina de estados del caso
Descripción textual de este diagrama
Un caso pasa por siete estados con nombre: recibido (un formulario estructurado más documentos de respaldo), clasificado y encaminado, enriquecido con política y contexto recuperados, evaluado con un borrador generado por IA y citas, una aprobación humana según consecuencia, procesado en los sistemas de registro, y luego cerrado y auditado.
El flujo de trabajo es determinista; la IA asiste solo dentro del estado «evaluado». En la puerta de aprobación, un caso de baja consecuencia puede aprobarse y procesarse, mientras que un caso que falla una verificación se devuelve o se escala (la ruta de excepción discontinua) y reingresa en «enriquecido». Cada transición se registra en el registro de auditoría.
Roles y traspasos
- Los servicios de recepción y flujo de trabajo reciben, clasifican, enriquecen y encaminan — sin esfuerzo humano en pasos administrativos.
- Los gestores de casos revisan el borrador de la IA y sus citas, lo corrigen, y deciden casos de consecuencia media.
- Los aprobadores senior tienen autoridad para acciones de alta consecuencia y firman en la puerta de aprobación.
Excepciones y casos límite
- Una verificación de política fallida devuelve el caso al enriquecimiento, o lo escala, en lugar de continuar.
- Los documentos faltantes o ilegibles pausan el caso y solicitan lo necesario — nunca producen una suposición silenciosa.
- El tiempo en un estado se rastrea, de modo que un caso no puede estancarse sin ser visto; el trabajo atrasado surge a un responsable.
Vista 03 · Arquitectura
Componentes, límites y datos.
Un orquestador determinista es la columna vertebral. Posee el flujo de trabajo y llama a servicios gobernados para el trabajo que los necesita, pero nunca les cede el control. El estado vive dentro de un límite de datos del caso.
Arquitectura del sistema
Descripción textual de este diagrama
Un orquestador de flujo de trabajo determinista dirige cada caso. Llama a tres servicios gobernados — recuperación (política y contexto previo), una pasarela de modelo (el borrador de IA), y un motor de política y reglas — pero nunca les cede el control. Los casos y documentos, y un registro de auditoría de solo anexado, viven dentro de un límite de datos de caso; el orquestador lee y escribe allí bajo mínimo privilegio.
Las acciones llegan a los sistemas de registro de la organización solo a través de adaptadores de integración, de modo que el límite y el registro de auditoría siempre ven primero cada cambio. La observabilidad — registros, métricas y trazas — abarca todo el sistema y se describe en la vista de evaluación.
Componentes
- Orquestador — el motor de flujo de trabajo determinista; el único componente que avanza un caso.
- Recuperación — obtiene la política y el contexto previo que un caso necesita, con procedencia.
- Pasarela de modelo — el único camino observable hacia el modelo de IA; aplica límites y registro.
- Política y reglas — verificaciones deterministas que el borrador debe superar.
- Adaptadores de integración — la única vía por la que las acciones llegan a los sistemas de registro.
Límites de datos
- Los casos, documentos y un registro de auditoría de solo adición viven dentro de un límite; el acceso es de mínimo privilegio.
- La pasarela de modelo envía solo el contexto mínimo necesario, y registra lo que se envió.
- Nada llega a un sistema de registro salvo a través de un adaptador que el límite pueda ver.
Las decisiones consecuentes se registran en el registro de decisiones de arquitectura.
Vista 04 · Control y riesgo
Autoridad, permisos y auditoría.
El control se diseña desde el principio, no se añade después. La autoridad para actuar se otorga en proporción a la consecuencia de la acción, los permisos están acotados por rol, y cada paso se registra.
Autoridad proporcional a la consecuencia
Descripción textual de este diagrama
La autoridad se concede en proporción a la consecuencia de la acción. Los pasos de baja consecuencia se ejecutan automáticamente dentro de límites explícitos. El trabajo de consecuencia media lo decide un gestor de casos con la asistencia de la IA. Las acciones de alta consecuencia requieren un aprobador senior.
Este es el modelo de autoridad humana detrás de la puerta de aprobación en la máquina de estados. Junto a él, los permisos de datos se acotan por rol: cada actor — humano o servicio — ve solo los datos del caso que su rol requiere.
Permisos y límites
- Los roles solo llevan los permisos que necesitan; un gestor de casos no puede aprobar una acción de alta consecuencia.
- Los servicios se ejecutan bajo mínimo privilegio — la pasarela de modelo no puede escribir en un sistema de registro.
- Cada actor ve solo los datos del caso que su rol requiere.
Las amenazas y mitigaciones se establecen en la especificación de amenazas, evaluación y aceptación.
Auditoría
El registro de auditoría es de solo adición y captura cada actor, acción y cita. Un extracto de un caso:
| Hora | Actor | Rol | Evento |
|---|---|---|---|
| 09:02:11 | Intake | servicio | Caso CASE-4837 recibido — formulario de solicitud + 2 documentos |
| 09:02:12 | Workflow | servicio | Clasificado: tipo=reclamación, prioridad=estándar, cola=A |
| 09:03:04 | Retrieval | servicio | Secciones de política P-12, P-19 recuperadas |
| 09:03:05 | Model gateway | servicio | Borrador de evaluación generado (3 citas) |
| 09:03:06 | Policy engine | servicio | Regla R-07 superada; R-11 marcada para revisión |
| 09:05:22 | u_214 | gestor de casos | Borrador editado; aprobación solicitada |
| 09:07:40 | u_038 | aprobador senior | Aprobado con condición |
| 09:07:41 | Integration | servicio | Acción publicada en el sistema de registro (SOR-99213) |
| 09:07:41 | Workflow | servicio | Caso cerrado; entrada de auditoría sellada |
Vista 05 · Evaluación
Cómo se mide y se acepta.
Un sistema como este solo es fiable si puede medirse y mantenerse a un estándar. La evaluación es continua: una versión se mide, debe superar una puerta de aceptación, y luego funciona bajo monitorización mientras los resultados retroalimentan.
Bucle de evaluación
Descripción textual de este diagrama
La evaluación es un bucle, no una aprobación puntual. Una versión se mide frente a conjuntos de datos y métricas definidos, y luego debe superar una puerta de aceptación cuyos umbrales se establecen de antemano. Solo entonces funciona — bajo monitorización que vigila la calidad, el coste, la latencia y las anulaciones humanas.
Los resultados operativos retroalimentan la siguiente mejora, y el sistema modificado se evalúa de nuevo antes de aceptarse. Los conjuntos de datos, las métricas y los umbrales se exponen en la especificación de amenazas, evaluación y aceptación.
Qué se mide
- Precisión de extracción — ¿lee el sistema los documentos correctamente?
- Fundamentación — ¿está cada afirmación de la IA respaldada por una cita recuperada?
- Precisión y recall de la verificación de política — ¿se marcan los casos correctos?
- Tasa de anulación humana — ¿con qué frecuencia los gestores corrigen el borrador?
- Corrección de la escalada — ¿los casos consecuentes llegan a un humano?
- Latencia y coste por caso — ¿es operable a volumen?
Aceptación y recuperación
- Se fijan umbrales para cada métrica antes de aceptar una versión; una versión que los incumple no se despliega.
- La monitorización observa las mismas métricas en operación; la deriva desencadena una revisión.
- La gestión de fallos es explícita: reintentos con retroceso, cola de mensajes fallidos para casos envenenados, y una vía de recuperación documentada.
Los resultados medidos no se publican. Esta vista define los conjuntos de datos, métricas y umbrales con los que se evaluaría y aceptaría el sistema — no afirma cifras de producción, y aún no se ha realizado una revisión senior independiente.
Vista 06 · Fallo y recuperación
Qué ocurre cuando un paso falla.
La vista operativa mostró el camino esperado y sus excepciones; la vista de evaluación nombró la recuperación como un requisito de aceptación. Esta vista es ese requisito, ilustrado: una acción fallida se reintenta, luego se contiene, luego se recupera — nunca se pierde silenciosamente, y nunca puede corromper el caso.
Fallo y recuperación
Descripción textual de este diagrama
Cada acción se intenta de forma idempotente, de modo que se confirma exactamente una vez o no se confirma en absoluto. Una acción fallida no detiene la operación:
- Se reintenta con espera creciente, hasta un número acotado de intentos.
- Si sigue fallando, se envía a una cola de fallidos — se conserva de forma segura, nunca se descarta silenciosamente.
- Un operador revisa la cola de fallidos, corrige la causa, y la repite.
- Como la acción es idempotente, la repetición no puede aplicar el efecto dos veces.
Toda la ruta permanece dentro de un límite de contención: un fallo no puede corromper el estado del caso, y cada intento, fallo y repetición se escribe en el registro de auditoría.
Modos de fallo gestionados
- Un error transitorio en un sistema descendente reintenta con retroceso acotado.
- Un fallo persistente se envía a una cola de mensajes fallidos, no se descarta, de modo que ningún caso desaparece.
- Una carga envenenada no puede repetirse indefinidamente; llega a la cola de mensajes fallidos para un humano.
- Un envío duplicado se resuelve en un único efecto confirmado (idempotencia).
Garantías de recuperación
- Cada intento, fallo y repetición se escribe en el registro de auditoría de solo adición.
- Un operador puede inspeccionar una cola de mensajes fallidos, corregir la causa, y repetirla.
- La repetición no puede aplicarse doblemente, por lo que la recuperación es segura de ejecutar.
Vista 07 · Despliegue y propiedad
Dónde se ejecuta, y quién lo posee.
La vista de control estableció el límite dentro del cual se ejecuta el sistema. Esta vista responde de quién es ese límite: suyo. El sistema se despliega en un entorno que usted controla, y la propiedad se transfiere en lugar de alquilarse.
Despliegue y propiedad
Descripción textual de este diagrama
El sistema se despliega en un entorno que usted controla — su cuenta en la nube, sobre infraestructura que posee o acepta — no una caja negra alojada por SageTensor.
La propiedad se transfiere, no se alquila. Usted recibe el código fuente y la infraestructura como código, los manuales operativos y los conjuntos de evaluación, y el historial de auditoría de solo anexado. SageTensor construye el sistema y lo entrega; solo lo opera durante el tiempo que usted decida, y usted puede ejecutarlo, modificarlo y auditarlo de forma independiente.
Dónde se ejecuta
- En su cuenta en la nube, sobre infraestructura que usted posee o acepta — no una caja negra alojada.
- Dentro del límite de control de la vista de control y riesgo, bajo mínimo privilegio.
- De forma reproducible, a partir de infraestructura como código, para que un entorno pueda reconstruirse.
Qué recibe usted
- El código fuente y la infraestructura como código de todo el sistema.
- Manuales de operación y los conjuntos de evaluación, para que pueda operarlo y volver a probarlo.
- El historial de auditoría de solo adición — es su registro, no el nuestro.
Cómo un encargo construye y transfiere esto es el tema de Entrega, y lo que usted posee se establece en Control empresarial.
Lo que esto demuestra y lo que no demuestra
Demuestra
- Que SageTensor diseña toda la operación —recepción, flujo de trabajo, autoridad de decisión, controles, auditoría, recuperación y propiedad— como un solo sistema.
- Que la IA se coloca dentro de un flujo de trabajo determinista con autoridad humana explícita, nunca se deja actuar sin supervisión.
- Que el control, la evaluación y la gestión de fallos se diseñan desde el principio, no se añaden después.
No demuestra
- Ninguna cifra específica de rendimiento, coste o precisión en producción.
- La idoneidad para una organización particular sin su propio mandato y evaluación.
- Un resultado de cliente — no se representa ninguna operación real.
Cómo inspeccionarlo
Léala a través de siete vistas conectadas —ejecutiva, operativa, arquitectura, control y riesgo, evaluación, fallo y recuperación, y despliegue y propiedad— cada una disponible como HTML semántico. El registro de arquitectura y la especificación de amenazas/evaluación/aceptación se publican como artefactos completados.
Contratación
Empiece por lo que debe cambiar.
Así es como SageTensor diseña una operación completa. Una Definición de Mandato comienza el mismo trabajo para la suya.
También puede enviar una RFP, o solicitar un acuerdo de confidencialidad primero.