Seguridad y gobernanza
Autonomía sin perder control
Un Officer que puede leer tus sistemas y actuar sobre tus procesos tiene que ser gobernable de forma verificable, no de forma declarativa. Esta página describe cómo, y también qué cosas Ofyra deliberadamente no promete.
¿Cómo controla una empresa a sus AI Officers?
En Ofyra cada Officer tiene una lista cerrada de fuentes que puede leer y de acciones que puede materializar; el modelo de lenguaje no invoca herramientas, sino que emite una recomendación tipada que código determinista decide ejecutar o no; las acciones sobre sistemas externos se habilitan endpoint por endpoint y se validan contra esquema; las situaciones sensibles requieren aprobación humana; y cada paso relevante queda en un registro de sólo agregado con encadenamiento de hashes, exportable para auditoría.
Seguridad y gobernanza
Autonomía sin perder control.
Un Officer que puede leer tus sistemas y actuar sobre tus procesos tiene que ser gobernable de forma verificable. En Ofyra la garantía no es una instrucción escrita en un prompt: es la ausencia de la capacidad.
Permisos explícitos
Cada Officer tiene una lista cerrada de fuentes que puede leer y de acciones que puede materializar. Lo que no está en la lista no ocurre, y no ocurre porque el permiso no existe — no porque se le haya pedido al modelo que no lo haga.
Acciones autorizadas una por una
Las acciones sobre sistemas externos se habilitan endpoint por endpoint, con el payload validado contra esquema antes de salir y clave de idempotencia para que un reintento nunca duplique nada.
El modelo no ejecuta
El modelo de lenguaje no invoca herramientas: emite un objeto tipado validado contra un esquema, y qué se ejecuta lo decide código determinista. Un Officer no puede llamar a un sistema que no le correspondía porque no llama a nada.
Supervisión humana en el circuito
Las situaciones sensibles requieren aprobación, una persona puede tomar cualquier conversación en vivo, y el texto que va a salir se lee y se corrige antes de aprobarse. Aprobar un mensaje sin verlo sería firmar en blanco.
Auditoría de sólo agregado
Cada paso relevante emite un evento a un registro con encadenamiento de hashes: cualquier alteración posterior invalida la cadena. El registro es exportable para auditoría interna o externa.
Versionado de todo lo que decide
Políticas, conocimiento, reglas y configuración se versionan y se publican. Cada caso queda amarrado a la versión exacta que lo evaluó, de modo que una decisión pasada se puede explicar con la norma que regía entonces.
Trazabilidad reconstruible
La respuesta a una auditoría no es "lo decidió la IA". Es un export: qué fuente se leyó, qué política se aplicó con documento, sección y versión, qué recomendó el modelo, qué evaluación de riesgo tuvo, qué determinó la política de decisión y quién aprobó.
Control de acceso por rol
Los accesos a la consola se separan por rol y por área: administración, análisis y auditoría de sólo lectura. Un auditor puede revisar todo sin poder cambiar nada.
Ofyra no afirma que tu información nunca sale de tu empresa: los Officers usan modelos de lenguaje, y esa llamada sale por HTTPS al proveedor del modelo. Lo que sí es cierto, y es lo que importa, es que tus sistemas y tus permisos siguen bajo tu control: las credenciales son tuyas y revocables, los endpoints de escritura los expones y autorizas tú, y el Cerebro Corporativo es tu activo exportable.
Trazabilidad
Qué contiene el registro de una decisión.
La prueba de que un sistema de IA es auditable no es que guarde logs: es qué puede responder cuando alguien pregunta «¿por qué se hizo esto?». La respuesta en Ofyra es un export, no una reconstrucción.
Cada evento incluye el hash del anterior, de modo que cualquier alteración posterior invalida la cadena.
- Fuente leída
- Qué conector, qué registro, sincronizado a qué hora.
- Política aplicada
- Documento, sección y versión que estaba vigente.
- Reglas evaluadas
- Qué condiciones se cumplieron, y con qué versión del snapshot publicado.
- Recomendación del modelo
- Qué propuso, qué citó como respaldo y con qué autoevaluación.
- Evaluación de riesgo
- El nivel calculado y los factores que lo produjeron.
- Desenlace
- Qué determinó la política de decisión: autoejecuta, sugiere, escala o bloquea.
- Intervención humana
- Quién aprobó, editó o rechazó, cuándo y con qué motivo.
- Resultado de la acción
- Qué se envió, a qué endpoint y qué respondió el sistema.
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.
Evaluación de riesgo
El nivel de riesgo se calcula fuera del modelo.
La confianza que un modelo declara de sí mismo no es una probabilidad calibrada. El nivel de riesgo de cada paso lo produce un cálculo determinista sobre cuatro factores verificables.
Evidencia completa
¿Están todos los hechos que este tipo de caso exige, o faltan piezas?
Cobertura de política
¿El conocimiento vigente cubre el caso con una sección aplicable, o el modelo está extrapolando?
Frescura de los datos
¿El conector sincronizó a tiempo, o estaríamos decidiendo con datos de hace tres días?
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.
Lo que no prometemos
Tres frases que sonarían mejor y serían falsas.
En una conversación con un equipo de seguridad, prometer de más cuesta más caro que prometer con precisión. Estas son las tres afirmaciones que Ofyra evita, y lo que dice en su lugar.
Lo que Ofyra no afirma
«La información nunca sale de tu empresa.»
Lo que sí es cierto
Los Officers usan modelos de lenguaje, y esa llamada sale por HTTPS al proveedor del modelo. Es la única salida de red obligatoria, y decirlo con precisión es parte de poder sostener la conversación con tu equipo de seguridad.
Lo que Ofyra no afirma
«Nada sale sin firma humana.»
Lo que sí es cierto
Sería falso, y volvería inútil al producto. Lo cierto es más preciso: la autonomía se configura por tipo de acción y nivel de riesgo, y hay categorías —comprometer, pedirle algo a una persona— que ninguna configuración vuelve automáticas.
Lo que Ofyra no afirma
«Nuestra IA decide.»
Lo que sí es cierto
El modelo emite una recomendación con su evidencia citada. Lo que se ejecuta lo determina una política de decisión que es código y configuración de tu organización.
Revisemos juntos la arquitectura para tu empresa, con tu equipo de TI en la reunión.
Agendar una sesiónPreguntas frecuentes
Sobre seguridad y control.
¿Ofyra escribe directamente en mis bases de datos?
No, y no es una configuración que se pueda cambiar: la capacidad de escribir en la base de datos de un cliente no existe en la plataforma. Cuando un proceso necesita registrar algo en un sistema de la empresa, la acción se ejecuta llamando a una API que la propia empresa expone y autoriza endpoint por endpoint, con el payload validado contra un esquema, clave de idempotencia para no duplicar nunca y registro de cada llamada.
¿Ofyra puede instalarse on-premise?
Sí. La plataforma se empaqueta como un conjunto de imágenes versionadas más servicios estándar, y se instala con el mismo procedimiento en la nube gestionada por Lilab, en la cuenta cloud del cliente o en su propia infraestructura. Lo único que distingue un despliegue de otro es su configuración declarativa y sus secretos. La única salida de red obligatoria es la llamada HTTPS al proveedor del modelo de lenguaje.
¿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ó.
¿Se entrena un modelo con los datos de mi empresa?
No. El conocimiento de tu organización se entrega al modelo como contexto en cada ejecución, en su versión vigente y aprobada, y el Cerebro Corporativo sigue siendo tu activo exportable. La mejora de los Officers ocurre por un ciclo de ingeniería —las correcciones humanas se convierten en casos de prueba y las versiones nuevas se contrastan contra casos históricos antes de liberarse—, no por ajustar los pesos de un modelo con tus datos.
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