Operaciones asistidas por IA, sin que los datos salgan de tu entorno
El trabajo repetitivo de una guardia —recoger el estado de un servicio, cruzar logs y métricas, comparar con el último despliegue, redactar el resumen del incidente— se puede asistir con un agente que tenga acceso de lectura a Kubernetes, a los logs y a las métricas a través de MCP. Lo montamos desplegado en vuestro entorno, on-premise o en vuestra propia nube, con las acciones de escritura detrás de aprobación humana. Está pensado para sectores que no pueden mandar sus datos de operación a una herramienta SaaS de terceros.
Última actualización:
Quitar el trabajo mecánico de la guardia
Para quién es
Para equipos que ya tienen un proceso de incidentes que funciona y quieren quitarle el trabajo mecánico, y para organizaciones que no pueden usar las herramientas SaaS de operación asistida porque sus datos no pueden salir del entorno: sanidad, sector público, defensa, entidades financieras y sus proveedores.
Qué problema resuelve
Que los primeros veinte minutos de un incidente son casi siempre los mismos veinte minutos: abrir cinco pestañas, mirar el estado de los pods, buscar el pico en el panel, comprobar si hubo despliegue, leer los logs del servicio de al lado. Eso se puede recoger y resumir solo, y el tiempo que se ahorra es tiempo de la persona que está decidiendo qué hacer.
Qué NO es
No es remediación automática, y no lo recomendamos como punto de partida. El agente lee, correlaciona, propone y redacta; ejecutar lo propuesto es una decisión de una persona, y las acciones de escritura van detrás de aprobación explícita y registrada. Tampoco sustituye los runbooks escritos: los usa, y de hecho obliga a tenerlos en condiciones.
Las tres piezas
Runbooks agénticos
Los procedimientos que ya tenéis escritos, ejecutables paso a paso por un agente con las comprobaciones automatizadas y las decisiones marcadas como humanas.
Copiloto de incidentes
Recoge el contexto en cuanto salta la alerta: estado, logs, métricas, cambios recientes e incidentes parecidos, resumidos en el canal donde ya trabajáis.
Dentro de vuestro perímetro
Desplegado on-premise o en vuestra nube, con los conectores MCP en lectura, permisos mínimos y registro de todo lo que el agente consulta y propone.
Cómo está montado
Conectores
Servidores MCP para lo que ya tenéis: Kubernetes, la plataforma de logs, las métricas, el repositorio y el sistema de despliegue, el registro de incidencias. Cada uno con su propia cuenta de servicio, permisos mínimos y, por defecto, solo lectura.
Modelo y despliegue
El modelo puede ser propio en vuestra infraestructura o uno comercial con la conexión bajo vuestro contrato y vuestras condiciones de retención. Lo decidimos con vuestro responsable de seguridad, y queda escrito qué datos ve el modelo, qué no sale del perímetro y qué se registra. Si la respuesta es que ningún dato puede salir, se monta con modelo local y se dice qué capacidad se pierde a cambio.
Barreras
Lista blanca de acciones, aprobación humana obligatoria para cualquier escritura, límites de alcance por entorno —producción aparte— y traza completa de peticiones y respuestas. Se prueba primero en preproducción y con incidentes pasados, para ver si sus conclusiones habrían sido útiles antes de dejarle hablar en un incidente real.
Qué os queda
El código de los conectores y de los runbooks en vuestro repositorio, la configuración como código y la documentación. Nada de esto depende de que sigamos nosotros.
Cómo trabajamos
Caso de uso
Qué parte de la guardia duele más. Se empieza por uno o dos procedimientos concretos, no por «conectar la IA a todo».
Conectores en lectura
Acceso mínimo a Kubernetes, logs, métricas y despliegues, con cuentas propias y registro desde el primer día.
Prueba sobre incidentes pasados
Se mide con incidencias reales ya cerradas: qué habría contestado y si habría ayudado. Si no ayuda, no se despliega.
Despliegue y barreras
Puesta en marcha en vuestro entorno, aprobación humana para escrituras y revisión periódica de lo que el agente propone.
Preguntas frecuentes
¿Va a tocar producción por su cuenta?
No con nuestra configuración por defecto. Los conectores entran en lectura, las acciones de escritura requieren aprobación humana explícita y quedan registradas, y producción tiene alcance separado. Ampliar eso es una decisión vuestra y se hace servicio a servicio, no de golpe.
¿Salen nuestros datos de operación a un tercero?
Depende de lo que decidáis y queda escrito antes de montar nada. Con modelo local no sale nada del perímetro. Con un modelo comercial sale lo que el agente le mande como contexto, bajo vuestro contrato y vuestras condiciones de retención, y el diseño incluye qué campos se filtran antes de enviarlos.
¿Y si el modelo se equivoca?
Se equivoca, y el diseño parte de eso: propone con las fuentes a la vista para que se pueda comprobar, no afirma sin enlace, y no ejecuta. La prueba con incidentes pasados sirve justo para medir cuánto acierta antes de que nadie confíe en él.
¿Necesitamos tener ya una plataforma de observabilidad buena?
Necesitáis que los datos existan y se puedan consultar. Si la instrumentación es pobre, el agente también lo será: en ese caso lo honesto es empezar por la observabilidad y dejar esto para después.
¿Con qué herramientas trabajáis?
Kubernetes y Terraform para la infraestructura, ArgoCD para GitOps, OpenTelemetry para la telemetría y Prometheus, Grafana, Loki y Tempo para mirarla. Son herramientas abiertas y estándar a propósito: cualquier ingeniero del mercado puede continuar el trabajo, y vosotros podéis dejar de contar con nosotros sin tener que rehacerlo.
No tenemos Kubernetes. ¿Sirve igual?
Sí. Los SLOs, las alertas con dueño, el proceso de incidentes y los postmortems valen igual sobre máquinas virtuales, contenedores sueltos o servidores propios. Kubernetes es una herramienta frecuente, no un requisito, y no lo recomendamos cuando no hay volumen que lo justifique.
¿Hace falta cambiar de proveedor de cloud para empezar?
No. El trabajo de fiabilidad se hace sobre lo que ya tenéis, sea AWS, Azure, Google Cloud, un proveedor europeo o vuestro propio hardware. La migración es otro servicio y solo tiene sentido si hay una razón para hacerla.
Cuéntanos qué parte de la guardia duele
Con un par de procedimientos vuestros y el inventario de herramientas basta para decir si esto os sirve. Respondemos en menos de 24 horas laborables.
o escríbenos a info@esdis.es