Saltar al contenido
Estándar de confianza pública

Cuando el trabajo con IA sale mal: contenerlo, decir la verdad y cambiar el encargo

Un plan de incidentes debería poder usarse a las 2 a. m. por alguien que no escribió la política.

Publicado el 24 de agosto de 2026 · Revisado frente a los límites actuales del producto

Qué cuenta como incidente

  • Información del cliente o de la empresa llegó a la persona o cuenta equivocada.
  • Ocurrió una acción externa fuera de la regla aprobada.
  • El sistema generó un dato falso importante o se apoyó en él.
  • Un proveedor o flujo de trabajo conectado falló sin avisar.
  • El acceso siguió activo después de que debió eliminarse.
  • Un cambio de modelo, prompt, integración o registro alteró de forma significativa el comportamiento del trabajo.

La primera hora

  • Detén o acota el trabajo afectado.
  • Conserva los registros y los datos relevantes.
  • Revoca o reduce el acceso si la conexión está implicada.
  • Nombra a un responsable de incidentes.
  • Identifica los clientes, registros y acciones externas afectados.
  • No especules en la comunicación con el cliente.

Los próximos pasos

Corrige los efectos externos reversibles. Determina si aplican deberes de notificación legal, contractual, de seguridad, de privacidad, de seguros o regulatoria. Dile a las personas afectadas qué pasó, qué información o acción estuvo involucrada, qué está contenido y qué deben hacer.

Encuentra la causa de sistema detrás de la mala salida: diseño del trabajo, registro de origen, permiso, regla de aprobación, comportamiento del proveedor o revisión humana.

Cierra el incidente con un cambio

Documenta la cronología, el alcance, la causa, la corrección y el nuevo control. Vuelve a probar el trabajo antes de restaurarlo. Un ticket cerrado con un flujo de trabajo sin cambios no es un incidente resuelto.