Todo lo que suelen preguntar sobre Ofyra

Ofyra es una plataforma empresarial de empleados digitales con inteligencia artificial, desarrollada por Lilab. Sus AI Officers son agentes de IA especializados que ejecutan y supervisan procesos completos de negocio —en ventas, Recursos Humanos, finanzas y operaciones— utilizando los sistemas, las reglas, los permisos y el conocimiento de cada organización.

Un AI Officer es un agente de inteligencia artificial especializado en un proceso empresarial concreto. A diferencia de un chatbot, no espera a que alguien le escriba: vigila el proceso, consulta los sistemas de la empresa, aplica reglas deterministas, interpreta las situaciones ambiguas, ejecuta las acciones que tiene autorizadas, hace seguimiento y escala a una persona lo que requiere criterio humano. Cada Officer tiene identidad, horario, permisos explícitos y reglas de escalamiento definidas por la organización.

No. Un chatbot necesita que alguien inicie la conversación y su resultado es una respuesta. Un Officer puede activarse por un evento, un horario o una condición de negocio, consultar sistemas, aplicar reglas, ejecutar acciones autorizadas y hacer seguimiento. Conversa cuando el proceso lo requiere, pero la conversación es un canal, no la función.

Un copiloto asiste a una persona que sigue siendo el operador del proceso: propone y acelera, pero el trabajo lo ejecuta el humano. Un Officer tiene una responsabilidad asignada sobre el proceso: lo vigila, lo ejecuta dentro de sus límites y devuelve a una persona sólo lo que necesita criterio humano.

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.

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ó.

Hoy el catálogo cubre ventas (atención y calificación de leads), Recursos Humanos (asistencia, vacaciones, contratos, atención al colaborador), finanzas (conciliación de tesorería, rendiciones y comprobantes) y operaciones (vigilancia de procesos y gestión de excepciones). Un tipo de Officer nuevo es un desarrollo de Lilab con sus propias pruebas, no un formulario a completar: es lo que permite garantizar su calidad.

Depende de tres cosas: qué tan disponible está la información que el Officer necesita leer, qué tan escrita está la política que debe aplicar, y cuántas acciones tienen que volver a tus sistemas. Los dos primeros son casi siempre el camino crítico, no la tecnología. En la primera sesión revisamos un proceso real y te decimos qué falta, con qué se puede empezar y qué conviene dejar para después.

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.

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 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ó.

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.

A través del Cerebro Corporativo. Las políticas, procedimientos y manuales se cargan como documentos con estado editorial, versión, vigencia y aprobador. Al publicar una versión, el conocimiento de los dominios que le corresponden a cada Officer se compila y pasa a ser parte de su contexto en todos los casos. No hay entrenamiento del modelo con tus datos: hay conocimiento versionado que se le entrega en cada ejecución.

Es el conocimiento de tu organización dentro de Ofyra: políticas, procedimientos, manuales, reglas y documentos, con estado editorial (borrador, en revisión, aprobado, vigente), versión, vigencia y aprobador registrado. Es un activo del cliente: se edita con un flujo editorial propio y es exportable. Cuando una decisión necesita explicación, Ofyra puede registrar qué información y qué versión de qué política se utilizaron.

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.

Sí, mediante lectura de solo lectura: una consulta a la base de datos con credenciales restringidas, una API REST que el ERP exponga, o un archivo que el ERP genere y deposite por SFTP, OneDrive o correo. Si el proceso exige devolver información al ERP, se habilita un endpoint específico de su API, autorizado uno por uno y con cada llamada auditada.

Sí, con credenciales de solo lectura y consultas acotadas, con sincronización incremental. Los datos se normalizan a un formato canónico antes de que el Officer los use, de modo que el mismo Officer funciona igual sobre una base de datos que sobre un archivo delimitado.

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.

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.

El RPA automatiza secuencias deterministas y lo hace bien. Ofyra combina esa lógica exacta con interpretación mediante IA, conversación, contexto corporativo, vigilancia continua, seguimiento y escalamiento humano. La diferencia práctica aparece cuando el caso no es el previsto: un flujo de RPA se detiene, y un Officer interpreta, decide según la política de la empresa y escala con el expediente armado si no le corresponde.

ChatGPT es un asistente de propósito general al que una persona le hace preguntas. Ofyra es una plataforma de procesos: sus Officers están conectados a los sistemas de la empresa, razonan con el conocimiento corporativo versionado, ejecutan acciones autorizadas, tienen horario y permisos, y dejan un registro auditable. Ofyra usa modelos de lenguaje internamente, a través de una única salida controlada, pero el modelo nunca produce una decisión ejecutable.