DeskIA — Gobierno de IA para ITSM

One-pager · para dirección y auditoría

IA que resuelve tickets y que además puedes auditar, gobernar y contener — corriendo sobre el backend de ITSM que ya tienes.

La pregunta que su organización debe poder responder antes de poner IA en la mesa de ayuda: «Si una IA puede resetear contraseñas, dar accesos y cerrar tickets… ¿quién la controla, qué tiene permitido hacer, y podemos demostrar después qué hizo y por qué?»

DeskIA está diseñado para que la respuesta sea sí, con evidencia — no con confianza.

Qué es

Un equipo de agentes de IA alineados a ITIL (incidentes, problemas, cambios, solicitudes) que opera sobre su propio sistema de ITSM (ManageEngine hoy; arquitectura multi-backend). El control y el dato se quedan en su casa: DeskIA no es una suite cerrada a la que migra sus datos. Resuelve apoyándose en la base de conocimiento aprobada de su organización (no improvisa) y atiende a cada usuario en español o inglés de principio a fin.

El marco de gobierno (no es "la IA se porta bien" — son controles en código)

Verificación de identidad (C1)Ninguna acción de cuenta se ejecuta sin verificar identidad. El recovery de credenciales exige un canal out-of-band — nunca una auto-confirmación por chat.

Lista de acciones permitidas (C2)DeskIA solo ejecuta acciones de una allowlist explícita. Que un plan diga "agregar a Domain Admins" no es autorización: se rechaza.

Entrada no confiable (C3)El texto del ticket es dato a clasificar, nunca instrucciones a seguir. Bloquea inyección de prompts ("ignora las instrucciones anteriores…").

Cadena de auditoría a prueba de manipulación (C5)Cada acción y transición emite un evento encadenado por hash. Borrar o editar rompe la cadena y se detecta. Sin evento = no ocurrió.

Presupuesto y cortacircuitos (C7/C9)Límite de operaciones por ticket y breaker ante fallos repetidos: DeskIA no se dispara sin tope ni entra en bucles.

Gate de calidad 95/100 (QA)Toda resolución se puntúa contra una rúbrica; por debajo de 95 no cierra. Hard-zeros de seguridad: una acción de cuenta sin verificación = falla automática + alerta de integridad.

Redacción de datos personales en la KB (C6/C8)Antes de escribir a la base de conocimiento, DeskIA redacta correos, teléfonos, IPs e identificadores; el artículo nace en cuarentena y nada se publica sin aprobación humana. Defensa en capas, no confianza ciega.

Respaldo verificado de la auditoríaLa cadena de eventos (C5) se respalda cada noche con un backup verificado que prueba su integridad antes de confiar en ella. La evidencia sobrevive a la pérdida del host.

Modelo de amenazas (T1-T8) mapeado a OWASP Agentic Security (ASI) Top 10. Controles deterministas en lugar de "otra IA vigilando a la IA".

Las preguntas del board, respondidas

Lo que pregunta dirección / auditoría	Cómo lo resuelve DeskIA
¿Puede DeskIA hacer cambios sin autorización?	No — allowlist (C2) + matriz de aprobaciones en código; lo no listado se deriva a un humano. ✓
¿Podemos demostrar qué hizo y cuándo?	Sí — cadena de auditoría inmutable por hash (C5), verificada cada noche. ✓
¿Dónde viven nuestros datos?	En su backend de ITSM. DeskIA opera sobre él; no migra ni encierra el dato. ✓
¿Y si una cuenta está comprometida?	El recovery exige verificación out-of-band; DeskIA nunca entrega credenciales por el mismo canal en disputa. ✓
¿Quién maneja un incidente de seguridad?	Se enruta a una cola de seguridad humana; DeskIA no "restaura" sobre un posible ataque (contención primero). ✓
¿Puede DeskIA gastar sin control?	No — tope de operaciones y costo por ticket, medido y visible en el panel ejecutivo. ✓
¿Y los datos personales que aparecen en los tickets?	Se redactan antes de llegar a la base de conocimiento (C6) y un humano aprueba cada artículo (C8). Los nombres los revisa esa persona — el control no se delega a un regex. ✓
¿El diagnóstico en el equipo instala un agente que vigila?	No — es read-only, a demanda y con consentimiento; se distribuye firmado y corre bajo AllSigned (un ejecutable suplantado se bloquea). Lee estado de máquina, no archivos del usuario; el output entra como dato no confiable (C3) y queda auditado (C5). ✓
¿Y si perdemos el servidor con la evidencia?	Backup nocturno verificado de la cadena de auditoría: se prueba integridad y encadenamiento sobre la copia. La evidencia es recuperable. ✓

DeskIA vs. suites cerradas (por categoría)

Eje de decisión	DeskIA	Suites cerradas
¿Dónde vive el dato?	En su backend de ITSM ✓	En la nube del proveedor (migra)
¿Quién controla la auditoría?	Cadena propia, inmutable y respaldada ✓	La que el proveedor muestre
Salida / lock-in	Se va; su sistema queda intacto ✓	Mudanza de salida
Datos personales en la KB	Redactados + aprobación humana ✓	Según la plataforma
Lógica que decide	Specs abiertos, editables ✓	Propietaria, caja negra

Comparación por categoría. Verifique las especificaciones de cada proveedor antes de citarlo por nombre; cada ✓ de DeskIA se respalda con su artefacto real.

Alineación ITIL 5 (AI-native)

DeskIA mapea al modelo de capacidades 6C de ITIL 5 y constituye un artefacto de AI Governance presentable a auditoría:

ClarificationCognitionCreationCurationCommunicationCoordination

Principios de diseño

· Controles deterministas > juicio del modelo en lo crítico.
· Mínimo privilegio: credenciales separadas por función.
· Contención antes que restauración en seguridad.
· El humano decide lo irreversible; la IA hace lo rutinario y auditable.

¿Va a evaluar IA para su mesa de ayuda este año?

Diagnóstico ITIL de 30 min: dónde la IA le ahorra, dónde le arriesga, y cómo gobernarla.

Agendar diagnóstico →