Cómo funciona
Qué pasa, exactamente, entre el disparador y la acción
Esta página describe el mecanismo. No hay magia en el medio: hay un pipeline con cuatro responsabilidades separadas y una política de decisión que determina qué se ejecuta y qué espera a una persona.
¿Quién decide qué, dentro de Ofyra?
El código calcula, las reglas deciden lo determinista, la IA interpreta lo ambiguo y las personas gobiernan lo sensible. Ofyra separa deliberadamente esas cuatro capas: los cálculos y cuadres se hacen con lógica exacta, las políticas de la empresa se evalúan con un motor de reglas versionado, el modelo de lenguaje interpreta y redacta pero nunca produce una decisión ejecutable, y la organización define qué acciones necesitan aprobación de una persona.
La vida de un caso
Nueve pasos, siempre los mismos.
Cambia el proceso, cambian los sistemas y cambian las reglas. El recorrido no: todo caso de todo Officer atraviesa este pipeline, y cada paso emite su propio evento de auditoría.
Se despierta
Un mensaje, un evento, un archivo, un cambio en un sistema, un horario, una vigilancia periódica o una condición de negocio. También la ausencia de algo que debía ocurrir.
Consulta
Lee los sistemas de la empresa a través de sus conectores, con permisos de solo lectura, sobre datos ya normalizados a un formato canónico.
Calcula
Los agregados, cuadres, ventanas y validaciones se resuelven con lógica determinista. Lo que debe ser exacto no se estima.
Aplica reglas
El motor de reglas evalúa las políticas de tu organización sobre hechos ya calculados, en la versión publicada que estaba vigente.
Interpreta
Con el conocimiento corporativo vigente, el modelo lee lo ambiguo y emite una recomendación tipada con su evidencia citada. No ejecuta nada.
Decide y actúa
La política de decisión cruza permisos, modo, reglas y riesgo, y determina el desenlace: autoejecuta, sugiere, escala o bloquea.
Escala si corresponde
Lo que necesita criterio humano llega a la persona responsable con la propuesta redactada y la evidencia adjunta.
Verifica
Si el caso quedó esperando algo —una respuesta, una aprobación, un resultado externo—, una vigilancia lo despierta a comprobar si ya ocurrió.
Documenta
Cada paso emite un evento al registro de sólo agregado: qué se leyó, qué regla y versión aplicaron, qué se propuso, qué se decidió y quién aprobó.
Cómo toma acciones
El código calcula. Las reglas deciden lo determinista.
La IA interpreta lo ambiguo. Las personas gobiernan lo sensible.
La pregunta que hace todo el mundo es la misma: ¿la IA decide sola? No. Ofyra separa deliberadamente cálculo, reglas, interpretación y gobierno, y esa separación no es una recomendación de uso: es cómo está construida la plataforma.
El modelo de lenguaje nunca produce una decisión ejecutable. Produce una recomendación con su evidencia citada, y qué se ejecuta lo determina una política que cruza permisos, modo de operación, reglas de tu empresa y evaluación de riesgo.
Ver el recorrido completo de un caso →- 01
El código calcula.
Cálculos, conciliaciones, agregados, ventanas de tiempo y validaciones: todo lo que debe ser exacto se resuelve con lógica determinista, no con un modelo de lenguaje. Un cuadre que un modelo "estima" no es un cuadre.
- 02
Las reglas deciden lo determinista.
Las políticas de tu organización se expresan como condiciones, umbrales y tablas de decisión versionadas. Son datos de tu empresa: se crean y publican en producción, y cada caso cita la versión exacta que lo evaluó.
- 03
La IA interpreta lo ambiguo.
Leer un mensaje, entender una justificación, clasificar una situación, redactar una respuesta, explicar una excepción. El modelo emite una recomendación con su evidencia citada — nunca una decisión ejecutable.
- 04
Las personas gobiernan lo sensible.
Aprobaciones, excepciones sensibles y decisiones de riesgo. La organización define qué necesita una firma humana, y hay categorías que no se automatizan por diseño, sin importar el historial del Officer.
Evaluación de riesgo
Por qué no se gobierna con la “confianza” del modelo.
Un modelo de lenguaje puede decir «0.87» con la misma soltura para un acierto que para una invención. Esa cifra no es una probabilidad calibrada, y construir el gobierno de un proceso sobre ella sería construir sobre arena.
En Ofyra el nivel de riesgo de cada paso lo produce un cálculo determinista sobre cuatro factores verificables en código. La autoevaluación del modelo es uno de los insumos — nunca el que gobierna.
- 01
Evidencia completa
¿Están todos los hechos que este tipo de caso exige, o faltan piezas?
- 02
Cobertura de política
¿El conocimiento vigente cubre el caso con una sección aplicable, o el modelo está extrapolando?
- 03
Frescura de los datos
¿El conector sincronizó a tiempo, o estaríamos decidiendo con datos de hace tres días?
- 04
Autoevaluación del modelo
Un insumo más del cálculo, nunca el que gobierna. La confianza que un modelo declara de sí mismo no es una probabilidad calibrada.
Autonomía configurable
Tú decides cuánta autonomía tiene cada Officer.
No es un interruptor de encendido y apagado. La autonomía se configura por tipo de acción y nivel de riesgo: un mismo Officer puede ejecutar solo las tareas rutinarias y exigir aprobación humana cuando la situación es sensible.
Antes de cualquier acción
permisos del Officer ∩ modo de operación∩ reglas de escalamiento∩ evaluación de riesgo
Todo lo que un Officer propone atraviesa esta política de decisión, y termina en uno de cuatro desenlaces.
Autoejecuta
Acción permitida y riesgo bajo.
El Officer ejecuta y deja registro. Es el desenlace de lo rutinario: informar un dato ya aprobado, consolidar información, enviar el resumen del día.
Sugiere
El Officer prepara la acción; una persona aprueba.
El trabajo llega hecho: la acción propuesta, el texto redactado y la evidencia. La persona lo lee, lo corrige si hace falta y lo dispara. Es la posición por defecto en lo que compromete.
Escala
El caso necesita criterio humano.
La evidencia está incompleta, la política no cubre el caso o el riesgo es alto. El caso llega a la persona responsable con la propuesta del Officer, o con constancia de que no tiene una.
Bloquea
La acción no está permitida.
Fuera de los permisos del Officer o por encima del umbral de riesgo. No hay forma de que ocurra: el permiso no existe, y sin permiso el runtime no materializa el paso.
Lo que no se puede configurar
Ofyra no promete que todo pase por una firma humana — sería falso, y haría inútil al producto. Promete algo más preciso: hay categorías de acción que ninguna configuración puede volver automáticas.
Comprometer siempre espera una firma
Reservar stock, garantizar una entrega, conceder un descuento fuera de lista o afirmar una cifra sin respaldo vigente. Ninguna configuración desactiva esta fila.
Pedirle algo a una persona también
Cuando el Officer le solicita algo al colaborador o al cliente del caso, del otro lado hay alguien a quien se le está pidiendo algo. Siempre pasa por aprobación.
La autonomía se gana con evidencia
Un Officer puede pedir operar sin aprobación mostrando su historial por tipo de acción y nivel de riesgo — con volumen y tasa mínimos. La decisión es de una persona.
Y se pierde de golpe
Un rechazo devuelve esa categoría al modo aprobación, y el historial vuelve a contarse desde ahí. La confianza se reconstruye, no se recupera automáticamente.
Una precisión técnica que cambia el gobierno
El modelo no invoca nada.
Es habitual explicar un agente de IA diciendo que “el modelo tiene herramientas y decide cuál usar”. En Ofyra no funciona así, y la diferencia es exactamente la que le importa a un comité de riesgos.
Lo que suele suponerse
Lo que hace la plataforma
El modelo elige una herramienta y la ejecuta.
El modelo emite un objeto tipado validado contra un esquema. Ejecutar o no lo decide código determinista.
Agregar una capacidad es darle una herramienta más al modelo.
Agregar una capacidad es agregar contexto: se le pone delante el dato que necesita, no una llave nueva.
Los permisos limitan qué herramientas puede llamar el modelo.
Los permisos limitan qué pasos puede materializar la plataforma. Para lo prohibido, el código que ejecutaría no existe.
La consecuencia práctica: un Officer no puede llamar a un sistema que no le correspondía, porque no llama a nada. Describe lo que haría, y la plataforma decide. La garantía no es una instrucción en un prompt que un modelo podría desobedecer: es la ausencia física de la capacidad.
¿Quieres ver este recorrido sobre un proceso concreto de tu empresa?
Agendar una sesiónPreguntas frecuentes
Sobre el funcionamiento y el control.
¿Puede un Officer actuar automáticamente?
Sí, dentro de los permisos y las reglas que la organización define, y de forma granular por tipo de acción y nivel de riesgo. Cada acción propuesta pasa por una política de decisión que cruza permisos, modo de operación, reglas de escalamiento y evaluación de riesgo, y termina en uno de cuatro desenlaces: autoejecuta, sugiere y espera aprobación, escala a una persona, o queda bloqueada. Hay categorías que no se automatizan por diseño: comprometer algo frente a un tercero y pedirle algo a una persona siempre esperan aprobación humana.
¿Qué pasa cuando un Officer no sabe qué hacer?
Escala, y escala con contenido. Un caso que queda esperando a una persona llega con una propuesta concreta —qué haría el Officer y por qué— o con constancia explícita de que no tiene una. No se fabrica una propuesta para llenar el hueco: alguien terminaría aprobando algo sin significado.
¿Puede una persona tomar el control?
Sí, en cualquier momento. Una persona puede tomar una conversación en vivo: el Officer se pausa y sigue registrando el hilo. También puede editar el texto que iba a salir antes de aprobarlo, rechazar una propuesta, o encargarle trabajo al Officer eligiendo la acción de una lista cerrada para que él redacte el mensaje.
¿Cada empresa puede tener reglas diferentes?
Sí. Las reglas de negocio son datos de tu organización: condiciones, umbrales y tablas de decisión que se crean y publican en producción, con versión y reversibles, sin esperar un despliegue. Lo que no cambia entre clientes es el motor que las interpreta, que es el mismo código probado para todos. Cada caso cita la versión exacta de la regla que lo evaluó.
¿Cómo se audita lo que hizo un Officer?
Cada paso relevante emite un evento a un registro de sólo agregado con encadenamiento de hashes, exportable para auditoría. La respuesta a "¿por qué se hizo esto?" no es una reconstrucción: es un export que contiene la fuente leída, la política citada con su documento, sección y versión, la recomendación del modelo con su evaluación de riesgo, el desenlace que determinó la política de decisión y quién aprobó.
¿Qué diferencia existe entre Ofyra y un agente de IA genérico?
Un agente genérico suele funcionar dándole herramientas al modelo para que elija cuál usar. En Ofyra el modelo no invoca nada: emite un objeto tipado validado contra un esquema, y ejecutar o no lo decide código determinista. La consecuencia es que un Officer no puede llamar a un sistema que no le correspondía, porque el código que ejecutaría eso no existe para lo prohibido. La garantía no es una instrucción en un prompt que un modelo podría desobedecer.
Veamos si un Officer puede hacerse cargo de tu proceso.
Una sesión de descubrimiento de 45 minutos: nos cuentas un proceso que hoy consume tiempo de tu equipo y evaluamos juntos qué partes podría asumir un Officer, con qué reglas y qué supervisión. Si ya hay un Officer listo para tu caso, lo ves funcionando en la misma sesión.
45 min · Revisamos un proceso real de tu empresa