Docs / 1. Fundamentos

Introducción a Orbis

Qué son los empleados digitales Orbis, cómo operan y en qué se diferencian de un chatbot tradicional.

Introducción a Orbis

Orbis es el sistema operativo de fuerza de trabajo digital (_AI Workforce OS_) desarrollado por Basilisk. A diferencia de un chatbot genérico que se limita a responder consultas superficiales basadas en FAQs, Orbis provee empleados digitales asignados a roles operativos específicos dentro de una empresa.

Cada empleado digital opera con un mandato claro, habilidades auditadas (_skills_), conectores a los sistemas nucleares de la empresa (PMS, ERP, pasarelas de cobro) y mecanismos de gobernanza con supervisión humana en bordes de riesgo.

Un empleado digital en Orbis no es un prompt enlatado ni una sesión efímera de chat. Es una entidad persistente con misión contractual, memoria operativa durable, identidad visual y sonora determinística, y presupuesto controlado en Unidades de Trabajo (UT).

---

¿En qué se diferencia de un Chatbot tradicional?

La industria del software con IA ha saturado el mercado con "asistentes virtuales" que no asumen responsabilidad operativa. Cuando surge una tarea real —como retener una habitación en el PMS, conciliar una transferencia o ajustar una tarifa de temporada— el bot colapsa y deriva al humano.

Orbis invierte este paradigma:

Dimensión	Chatbot Tradicional / Meta AI	Empleado Digital en Orbis
Propósito nuclear	Responder texto con probabilidad lingüística.	Ejecutar tareas completas y cerrar procesos de negocio.
Integración de sistemas	Silo cerrado dentro de la app de mensajería.	Lectura y escritura en ERPs, PMS y bases de datos locales.
Gobernanza y control	Caja negra: o responde solo o se desconecta.	Aprobaciones 4-Eyes: Pausa y pide permiso antes de comprometer fondos o acuerdos.
Privacidad y soberanía	Suele entrenar modelos de terceros con tus datos.	Aislamiento estricto: Cifrado AES-256-GCM y política zero-training.
Memoria de trabajo	Efímera o confinada a la ventana de contexto.	Memoria operativa estratificada con expiración de baja confianza.
Metrología de costos	Créditos oscuros o cobros por token impredecibles.	Unidades de Trabajo (UT) fijadas en retainer con tope diario garantizado.

---

Anatomía de un Empleado Digital

Cada integrante de la flota digital está definido por seis componentes inmutables y auditables:

┌─────────────────────────────────────────────────────────────┐
│                   EMPLEADO DIGITAL ORBIS                    │
├─────────────────────────────────────────────────────────────┤
│ 1. MISIÓN & BLUEPRINT      Rol, responsabilidades y límites │
│ 2. SKILLS AUDITADAS        Herramientas de software y APIs  │
│ 3. MEMORIA ESTRATIFICADA   Contexto, episodios y packs      │
│ 4. CONECTORES & PUENTES    Conexión local y nube segura     │
│ 5. MATRIZ 4-EYES           Reglas de autorización humana    │
│ 6. PRESUPUESTO EN UT       Tope diario y metrología real    │
└─────────────────────────────────────────────────────────────┘

1. Misión & Blueprint: Declara el propósito del puesto (ej: atencion, revenue, operaciones), los horarios de operación y las políticas de comunicación corporativa.

2. Skills Auditadas: Conjunto cerrado de capacidades de software (ej. consultar inventario en PMS, calcular cotización, emitir link de cobro Stripe/MercadoPago). Ningún empleado puede ejecutar herramientas no homologadas en su perfil.

3. Memoria Estratificada: Combina memoria inmediata de la conversación, memoria episódica durable (memory.db) y paquetes normativos versionados (_Knowledge Packs_).

4. Conectores & Puentes: Enlaces cifrados hacia APIs en la nube o hacia sistemas instalados en la red interna del cliente mediante el Edge Bridge.

5. Matriz 4-Eyes (HITL): Reglas que determinan cuándo una acción exige autorización humana previa antes de impactar en bases de datos o cuentas bancarias.

6. Presupuesto en UT: Cupo diario de Unidades de Trabajo que garantiza que el consumo de inferencia y cómputo permanezca dentro de los márgenes contratados.

---

Ciclo de Ejecución de una Tarea

El motor de ejecución de Orbis (_Harness TS_) procesa cada interacción bajo un protocolo estricto de gobernanza:

[Evento Inbound] (WhatsApp / Webhook)
       │
       ▼
[Egress & Ingest Gate] ─── Verificación criptográfica de firma
       │
       ▼
[Comprensión de Intención] ─── Consulta a Knowledge Packs normativos
       │
       ▼
[Planificación de Herramientas]
       │
       ├── ¿Involucra dinero o cambios irreversibles?
       │        ├── SÍ ──► [Estado PENDING] ──► Notificación WhatsApp al dueño
       │        │                                        │
       │        │                         [Humano responde "sí" / "APR-..."]
       │        │                                        │
       │        │                                        ▼
       │        └──────────────────────────────► [Ejecución de Skill]
       │                                                 │
       └── NO ───────────────────────────────────────────┘
                                                         │
                                                         ▼
[Escáner Egress DLP] ─── Filtrado de PII y secretos antes de emitir respuesta
                                                         │
                                                         ▼
[Registro en Trail] ─── Persistencia inmutable del run en runs.db

1. Ingesta Verificada: El mensaje entrante se valida criptográficamente (firma HMAC de Meta o Zernio) y se encola en jobs.db con clave de deduplicación durable.

2. Contexto & Políticas: El motor ensambla el prompt inyectando primero los Knowledge Packs versionados para aprovechar el _prefix caching_ del proveedor de inferencia, seguido de la memoria histórica relevante.

3. Detección de Borde de Riesgo: Si la tarea requiere cobrar, cancelar una reserva confirmada o modificar una tarifa base, el motor entra en estado pending y notifica al dueño a su WhatsApp personal.

4. Ejecución Protegida: Las respuestas de herramientas externas se encapsulan como datos no ejecutables (trust="untrusted"), neutralizando intentos de inyección de prompts.

5. Egress DLP: Antes de emitir cualquier texto al exterior, el escáner de egreso valida que no se filtren datos personales no consentidos ni claves internas.

6. Auditoría Permanente: Cada paso queda indexado en el rastro inmutable (_Trail_), accesible por el supervisor desde el panel de control.

---

Caso de Uso Real: Recepción y Cobro Hotelero

Para ilustrar la diferencia práctica, consideremos una solicitud típica en una empresa de hospitalidad:

Huésped (por WhatsApp): _"Hola, somos dos adultos y queremos quedarnos del 14 al 17 de noviembre. ¿Tienen disponible una suite matrimonial y cuánto saldría con desayuno?"_

1. Lectura de Sistema: El empleado digital de atencion consulta en tiempo real el PMS local del hotel a través del Edge Bridge. Confirma que la suite está libre y calcula la cotización según la política de temporada alta.

2. Respuesta & Retención: Informa la tarifa exacta, condiciones de cancelación y retiene temporalmente el cupo durante 20 minutos en el motor de reservas.

3. Intención de Pago: El huésped acepta. El empleado genera un enlace de pago seguro a través de la pasarela configurada y se lo envía.

4. Confirmación Automatizada: Al acreditarse el pago, el webhook de la pasarela despierta al empleado, quien asienta el número de reserva definitivo en el PMS, emite el comprobante y envía al huésped las instrucciones de check-in.

5. Cero Fricción para el Personal: Todo el ciclo ocurrió en 3 minutos sin que el recepcionista humano tuviera que desatender a los huéspedes que estaban en el mostrador físico.