VERTIKO
Agentes IA · La capa que piensa

Un copilot operativo. No un chatbot.

El Copilot Vertiko observa la telemetría en vivo, razona sobre los eventos, propone acciones específicas y crea órdenes de trabajo. Tú apruebas con un click. Audit log firmado en cada paso. Sin alucinaciones, con guardrails que tú defines.

Diferenciador

Por qué un agente y no un chatbot

Los chatbots actuales (ChatGPT, Claude, Copilot Microsoft) responden preguntas, generan texto, codifican. No operan infraestructura. No saben qué está pasando en tu sitio en este momento, no pueden ejecutar comandos contra tus equipos, y si los conectas mal pueden alucinar respuestas convincentes que no corresponden a la realidad.

Un agente operativo es distinto: tiene contexto en vivo de la operación, modelo de datos restrictivo que evita alucinaciones, y capacidad de ejecutar acciones —siempre dentro de guardrails que el cliente define y siempre con confirmación humana en las acciones críticas.

Vertiko Copilot es ese agente. No reemplaza al NOC: lo amplifica.

Arquitectura

Cómo está construido el agente

CapaFunciónTecnología base
Contexto en vivoLectura permanente de telemetría, OT abiertas, históricos, contratos SLAVertiko BMS + ERP como single source of truth
Modelo de razonamientoLLM con tool-use limitado a las funciones autorizadas del clienteModelos frontier con context window suficiente para el estado del sitio
Capa de propuestaGenera acción candidata + justificación + impacto estimadoSistema determinístico + LLM combinados
Cola de aprobaciónOperador humano ve la propuesta y aprueba/rechaza con un clickUI integrada al NOC, sin contexto perdido
EjecuciónUna vez aprobada, ejecuta vía API contra los equipos o el ERPAdapter pattern, mismo gateway que las automatizaciones
Audit log inmutableCada paso firmado con quién propuso, quién aprobó, qué se ejecutó, con qué resultadoAppend-only log con hash chain
Modos

Tres modos de operación

Modo consulta (siempre activo) — Responde preguntas sobre el estado de la operación en lenguaje natural:

  • "¿Qué sitios necesitan atención ahora?"
  • "¿Cuánto llevamos de uptime este mes en el cluster Norte?"
  • "Dame los 5 equipos con peor desempeño en febrero"

Respuestas con datos reales del ERP/BMS. Si le falta contexto, lo pide en vez de adivinar. Cero alucinaciones: nunca inventa nombres de equipos, números o fechas que no estén en el sistema.

Modo propuesta (activo durante operación) — Cuando detecta una situación accionable, prepara una propuesta concreta con botones Aplicar / Rechazar / Modificar. Cada propuesta queda registrada incluso si fue rechazada (útil para entender el sesgo del agente y ajustar guardrails).

Modo acción crítica (requiere doble autorización) — Para acciones de alto impacto: apertura del área de un cliente final, cambio de configuración en interruptor principal, modificación de umbrales de alarmas de seguridad vital. Estas requieren segundo factor de autenticación y, según política del cliente, un segundo operador que apruebe.

Salvaguardas

8 acciones que el agente NUNCA cruza

Hay acciones que el Copilot nunca ejecuta, sin importar el nivel de autonomía configurado, la insistencia del operador, o la urgencia aparente:

  • Apagar carga eléctrica que afecte servicios en producción
  • Cambios manuales en la transferencia de energía entre generador y red
  • Saltarse procedimientos de seguridad vital (incendios, evacuación)
  • Modificar umbrales de alarmas críticas sin doble aprobación
  • Permitir acceso físico a la zona de un cliente final sin biometría confirmada
  • Borrar o restablecer registros de auditoría
  • Cambiar configuraciones de seguridad o permisos de usuarios
  • Operar interruptores eléctricos principales del sitio

Estos guardrails están codificados a nivel de arquitectura, no como instrucciones al modelo. Aunque el LLM "decidiera" hacerlo, la capa de ejecución lo rechaza.

¿Quieres ver al agente operando en tu DC?

Demo técnica de 45 minutos con un escenario de tu operación. Sin slides corporativas, solo el agente leyendo telemetría y proponiendo acciones.

FAQ

Preguntas frecuentes

¿Qué pasa si el agente alucina y propone una acción incorrecta?+

Tres protecciones: (1) el agente trabaja con context restrictivo basado en datos reales del BMS/ERP, no inventa equipos ni números; (2) cada acción crítica pasa por aprobación humana con justificación visible; (3) hay 8 acciones que la capa de ejecución rechaza por arquitectura, sin importar lo que el LLM "decida". Si propone algo incorrecto, el operador rechaza con un click y la propuesta queda registrada para ajustar guardrails.

¿Qué nivel de autonomía tiene? ¿Puede ejecutar comandos sin que yo confirme?+

Tres modos: consulta (responde preguntas, no actúa), propuesta (sugiere acción que el operador aprueba con un click) y acción crítica (requiere segundo factor de autenticación y a veces un segundo operador). El nivel por defecto es modo propuesta. La autonomía sin confirmación humana es opcional y solo aplica a acciones de bajo impacto que tú definas explícitamente.

¿El audit log es realmente inmutable? ¿Cómo?+

Cada paso se firma criptográficamente con hash encadenado al evento anterior, estilo append-only blockchain. El log replica a almacenamiento WORM (Write Once Read Many) y se puede exportar para auditorías ISO 27001 o SOC 2. Editar un evento sin romper la cadena hash es computacionalmente inviable. Cumple requisitos de evidencia digital ante un juez en disputas con clientes finales.

¿Qué LLM usan? ¿OpenAI, Anthropic, modelo propio?+

Usamos modelos frontier de proveedores líderes (OpenAI, Anthropic) con configuración multi-vendor para resiliencia. El cliente puede elegir si su contexto pasa por modelo en la nube o por modelo en infraestructura privada (Azure OpenAI dedicado, AWS Bedrock dedicado). Para sitios con datos altamente sensibles ofrecemos despliegue de modelo open-source en infraestructura del cliente.

¿Cómo manejan datos sensibles (claves, accesos) en el contexto del agente?+

Claves, credenciales, tokens y datos personales identificables nunca pasan al contexto del LLM. Tenemos una capa de redacción que filtra antes de mandar al modelo: el agente "sabe" que hay un acceso pero no ve el credential. Las acciones que requieren credenciales se ejecutan vía servicio aislado, no por el LLM directamente.

¿Funciona offline si pierde conectividad con la API del LLM?+

En modo degradado, sí. Si pierde conectividad con el LLM, el sistema cae a modo reglas determinísticas (las automatizaciones siguen activas) y notifica al NOC. Las consultas conversacionales quedan en cola y se procesan cuando vuelve la conectividad. Lo crítico (alarmas, ejecuciones automatizadas) no depende del LLM, por diseño.

Escríbenos