Interrupción de la IA en contratación: cómo mantener la selección en marcha

Un plan para mantener la selección durante una interrupción de la IA conserva las candidaturas, las decisiones, las entrevistas y la comunicación entre personas dentro del ATS, mientras el enriquecimiento que depende de modelos falla por separado. Guarda primero la transacción del proceso de selección, pon las tareas de IA en cola junto con las versiones de los datos de origen, limita los reintentos, ofrece una vía manual y concilia las tareas desactualizadas antes de recuperar el servicio.

Esta distinción importa porque la IA ya no se limita a un asistente de redacción abierto en otra pestaña. Un modelo puede analizar un CV, resumir una entrevista, sugerir una respuesta, buscar registros o llamar a herramientas que cambian un pipeline de contratación. Si el modelo pasa a formar parte de la ruta que debe completarse antes de guardar los datos del proceso de selección, cualquier incidencia del proveedor pasa a afectarte directamente.

No se trata de prometer una automatización sin interrupciones, porque no es posible. Se trata de que el proceso de contratación siga siendo comprensible y utilizable cuando la automatización se detenga.

¿Qué demostró realmente la coincidencia de 93 minutos entre interrupciones de IA?

El 3 de septiembre de 2026, las incidencias confirmadas de Anthropic, xAI y OpenAI coincidieron durante 93 minutos, de las 14:43 a las 16:16 UTC. No comenzaron al mismo tiempo y las pruebas públicas no permiten establecer una causa común.

Anthropic abrió su incidencia principal a las 13:26 UTC por un aumento de los errores en varios modelos de Claude. Su registro de la incidencia incluye Claude.ai, la API de Claude, Claude Code y Claude Cowork entre los servicios afectados. La empresa afirmó haber identificado la causa, aunque públicamente solo habló de un problema de infraestructura. El impacto terminó a las 16:16 UTC, dos horas y 50 minutos después del primer aviso. Otra incidencia de Sonnet 5 había terminado a las 12:56 UTC, así que no conviene presentar ambos episodios como una única interrupción continua.

La interrupción de xAI comenzó a las 13:30 UTC. Su registro del estado de la API en US East muestra que el servicio se recuperó a las 17:07 UTC, mientras que la web, las aplicaciones móviles, la integración con X y otras superficies de la API registraron intervalos similares. SpaceXAI aludió más tarde a una interrupción en su centro de computación de Memphis. No publicó si el fallo afectó a la alimentación eléctrica, la red, el hardware o el software.

OpenAI situó el inicio del impacto a las 14:43 UTC. Su página de la incidencia menciona componentes de ChatGPT y Codex, no la API de OpenAI. Un portavoz atribuyó los problemas de algunos usuarios a un error de enrutamiento. La solución se aplicó a las 15:17 UTC, pero la supervisión continuó hasta que la incidencia se marcó como resuelta a las 16:55 UTC. Hablar de una interrupción de 34 minutos confundiría el tiempo hasta la mitigación con la resolución definitiva.

Que las tres incidencias coincidieran sí importa: desmonta la idea cómoda de que elegir un proveedor de IA famoso elimina el riesgo operativo. Lo que no permite la coincidencia temporal es afirmar que compartían una nube, una red, un centro de datos, un ataque o un pico de tráfico. En la información publicada durante las incidencias no aparece ninguna declaración de los proveedores que establezca ese vínculo. Trata cualquier explicación basada en una causa común como una especulación mientras no la confirme un análisis posterior.

Para un equipo de contratación, la pregunta útil no es por qué había tres páginas de estado en rojo, sino qué podían seguir haciendo tus candidatos y reclutadores mientras tanto.

¿Qué flujos de contratación deben sobrevivir a una interrupción de IA?

Las acciones que fijan el estado oficial del proceso de selección deben funcionar sin un modelo. Un fallo del proveedor puede retrasar el enriquecimiento, pero no debería borrar una candidatura, ocultar una decisión ni impedir que un candidato contacte con una persona.

Empieza por separar las transacciones de la asistencia. Las transacciones cambian el estado persistente del proceso de contratación. La asistencia genera información derivada o propone una posible acción posterior.

La frontera se define por quién conserva la autoridad, no por lo importante que parezca una función. Un reclutador puede apoyarse mucho en un resumen generado, pero las notas originales de la entrevista deben seguir existiendo. Un asistente de redacción puede ahorrar horas, pero el reclutador debe poder escribir un mensaje directamente. Un modelo de búsqueda puede mostrar las coincidencias más probables, pero una persona autorizada sigue necesitando otra forma de abrir la ficha del candidato.

El manual del Marco de Gestión de Riesgos de IA del NIST recomienda alternativas viables sin IA, funciones humanas, mecanismos para que una persona tome el control y procesos de contingencia ante fallos de terceros. En selección, eso descarta un modo degradado reducido a un indicador de carga que nunca termina. La interfaz debe explicar qué ha fallado, confirmar qué se ha guardado y ofrecer la siguiente acción segura.

También afecta a la experiencia del candidato. Si la candidatura queda registrada pero el análisis se retrasa, dile al candidato que la has recibido. No le obligues a enviarla de nuevo porque se haya agotado el tiempo de espera de una llamada de enriquecimiento. La misma idea que sustenta un portal del candidato accesible se aplica en este caso: el recorrido esencial debe seguir funcionando cuando una capa opcional no lo hace.

Define ese límite por escrito antes de que ocurra una incidencia. Ante cada función que utiliza un modelo, pregunta: ¿Qué registro existe si esta llamada nunca responde? ¿Qué puede hacer después una persona? Si ninguna de las dos respuestas está clara, probablemente el modelo tiene demasiado control sobre la transacción.

¿Cómo se separa la transacción del proceso de selección del enriquecimiento con IA?

Guarda primero los datos principales en tu sistema y solicita después el enriquecimiento con IA como una unidad de trabajo separada y observable. La acción que realiza el candidato no debería esperar la respuesta de un modelo, salvo que la función sea opcional de forma explícita y ofrezca una manera clara de continuar sin ella.

En la práctica, la ruta es esta:

candidate or recruiter action → ATS transaction → durable AI task → bounded worker → provider → versioned result → human review

Imagina que un candidato presenta su candidatura. Guarda los datos del candidato, la candidatura, el consentimiento, la referencia al archivo adjunto y la etapa inicial en una única transacción de base de datos. Solo después de confirmar esa transacción debería el sistema poner en cola la extracción o el resumen del CV. Si el proveedor no está disponible, la candidatura sigue existiendo. El reclutador ve «resumen pendiente» en lugar de una ficha vacía y el candidato recibe una confirmación a partir de la candidatura guardada, no del resultado del enriquecimiento.

Una cola persistente absorbe el trabajo mientras una dependencia no está disponible, pero no constituye por sí sola una estrategia de resiliencia completa. Las directrices de Microsoft sobre la nivelación de carga mediante colas señalan la necesidad de supervisar la profundidad de la cola, limitar el procesamiento, usar consumidores idempotentes, gestionar los mensajes no procesables y definir el orden de procesamiento. Sin esos controles, la recuperación puede convertir una interrupción del proveedor en una avalancha de trabajo atrasado.

Haz que cada tarea lleve una versión inmutable de los datos de origen. Puede ser una revisión del CV, de las notas de la entrevista, de los criterios del puesto o de la plantilla del mensaje. Antes de guardar un resultado, el proceso debe comparar esa versión con el estado actual. Si el candidato ha sustituido el CV o la candidatura ha avanzado, la tarea anterior no solo llega tarde: está desactualizada.

Cuando una tarea queda desactualizada, suele ser más seguro sustituirla que ejecutarla de nuevo. Consérvala para fines de auditoría, indica por qué se ha omitido y pon en cola una versión actual solo si el resultado todavía es útil. Así evitas que los reclutadores lean un resumen impecable de datos que ya no corresponden al estado actual de la candidatura.

La interfaz necesita la misma precisión. Utiliza estados distintos, como pendiente, en ejecución, en espera de un nuevo intento, fallido, sustituido, cancelado y completado. «IA no disponible» resulta más útil que un estado de carga interminable. «Candidatura guardada; resumen del CV retrasado» es aún mejor, porque identifica tanto la transacción completada como el enriquecimiento fallido.

¿Cómo hacer reintentos seguros antes de añadir otro proveedor?

Los reintentos solo son seguros cuando repetir una solicitud no puede repetir un efecto sobre el negocio. Resuelve eso antes de añadir otro proveedor de modelos, porque la conmutación crea otra ruta y aumenta el riesgo de ejecutar acciones duplicadas o desactualizadas.

Las tareas de IA se dividen en dos clases de riesgo. Generar dos veces un resumen interno malgasta dinero y puede crear documentos contradictorios. Repetir una acción dirigida al candidato o que cambia el estado puede causar un daño directo: dos correos de rechazo, dos reservas de entrevista, dos cambios de etapa o una oferta enviada después de que el candidato retire su candidatura.

Asigna a cada operación una clave de idempotencia vinculada a su efecto en el negocio. Un formato útil sería:

account + application + capability + source_version + workflow_step

Guarda esa clave junto con la tarea y cualquier documento o efecto secundario resultante. Antes de enviar un mensaje, programar una entrevista, rechazar una candidatura o cambiar una etapa, comprueba tanto la clave como el estado local actual. Las directrices de AWS sobre cómo hacer que los reintentos sean seguros mediante API idempotentes explican por qué un identificador proporcionado por quien realiza la llamada es más fiable que intentar deducir si dos solicitudes similares expresan la misma intención.

Elige después una sola capa de reintentos. Puede que un SDK ya haga reintentos. Tu proceso en segundo plano también podría hacerlos. Un motor de flujos de trabajo podría añadir otro bucle. Si cada capa realiza tres intentos, un solo fallo puede generar muchas más llamadas de las que parece permitir tu política. Usa errores transitorios tipados, esperas exponenciales con variación aleatoria, un límite y un plazo máximo. Un fallo de autenticación, una entrada no válida o una solicitud rechazada por motivos de seguridad no justifican seguir insistiendo.

No empieces por la conmutación entre proveedores. Modelos con nombres distintos aún pueden compartir el sistema de identidad, la red, la capacidad regional u otra dependencia del plano de control. El análisis de la incidencia de OpenAI de julio de 2026 describió un problema regional de capacidad del sistema de identidad en el que la conmutación automática redirigió demasiado poco tráfico. Para que la independencia sea real, tiene que cubrir la ruta por la que se produjo el fallo.

Si añades una alternativa, define qué puede hacer. Un segundo proveedor puede ser aceptable para un resumen interno de bajo riesgo. Puede no serlo para un CV sensible si los contratos, la residencia de los datos, la conservación o el comportamiento del modelo son distintos. Los resultados también pueden variar lo suficiente como para invalidar las suposiciones de los sistemas que dependen de ellos. Conserva los datos del proveedor y el modelo en el registro de auditoría, valida el resultado alternativo y mantén la ruta sin IA.

¿Cómo probar el modo degradado con un procedimiento de cinco pasos?

Para que un procedimiento sirva durante una interrupción, debe ser breve y explícito: fácil de seguir bajo presión, sin dejar espacio a la improvisación. Prueba estos cinco pasos con la conexión al modelo desactivada, no con una presentación.

1. Declara el modo degradado y protege la ruta principal

Confirma la incidencia del proveedor y después desactiva u omite las llamadas síncronas que no sean esenciales. Mantén disponibles la recepción de candidaturas, el acceso a los registros, los cambios manuales de etapa, la administración de entrevistas y las comunicaciones redactadas por personas. Muestra un mensaje de estado sencillo donde puedan verlo los reclutadores. Registra el inicio de la incidencia y quién coordina la recuperación.

2. Contén los reintentos y conserva la intención

Activa el cortacircuitos para la función afectada o pausa sus procesos consumidores. No elimines el trabajo en cola. Detén los reintentos encadenados en varias capas antes de que amplifiquen la carga o agoten los límites de frecuencia. Conserva la clave de idempotencia, la versión de los datos de origen, el plazo máximo, el identificador de solicitud del proveedor y el último error tipado de cada tarea.

Las directrices de SRE de Google sobre fallos en cascada recomiendan resultados degradados, plazos máximos, descarte de carga y una política de reintentos cuidadosa, porque el tráfico de los reintentos puede prolongar una sobrecarga. El objetivo es reducir la presión sin perder la intención original de la tarea de selección.

3. Dirige a las personas hacia una vía manual

Da a los reclutadores instrucciones específicas para cada función. Abre el CV almacenado en lugar de esperar un resumen. Usa palabras clave o una búsqueda en la base de datos en lugar de embeddings. Escribe directamente el mensaje para el candidato. Registra la decisión de etapa en el ATS en vez de pedirle a un agente que lo haga. Asigna responsables a las candidaturas y entrevistas con plazos ajustados para evitar que «IA pendiente» acabe significando «candidato olvidado».

Si tu equipo usa un asistente para manejar herramientas de selección, revisa los límites de permisos y aprobación descritos en cómo desplegar agentes de selección con IA mediante MCP. El contrato de la herramienta puede seguir disponible aunque el modelo que la maneja no lo esté.

4. Comprueba la recuperación con un presupuesto limitado

No liberes todo el trabajo atrasado cuando una página de estado se ponga verde. Envía un pequeño conjunto de tareas actuales y de bajo riesgo a través de un circuito en estado semiabierto. Vigila la latencia, la tasa de errores, las respuestas por límite de frecuencia, la edad de las tareas en cola y la validación de los resultados. Restablece los procesos consumidores de forma gradual y reserva capacidad para nuevas tareas relacionadas con candidatos.

5. Concilia el estado antes de volver a ejecutar tareas

Recuperar el servicio exige comparar los datos de la base, no limitarse a vaciar la cola. Para cada tarea pendiente o fallida, comprueba si la versión de sus datos de origen sigue vigente, si su plazo aún importa, si ya existe un documento equivalente o si una persona completó la acción manualmente. Concilia los efectos externos, como los correos y las reservas de calendario, antes de cualquier reintento.

Da prioridad a las comunicaciones actuales con candidatos y a las vacantes activas. Marca el trabajo desactualizado como sustituido. Cancela las tareas que ya no tengan utilidad para el proceso. Vuelve a ejecutar únicamente las tareas actuales con claves de idempotencia válidas y compara después los registros esperados con los reales. Conserva en la cronología de la incidencia los recuentos de tareas completadas, omitidas, canceladas y resueltas manualmente.

Realiza este ejercicio cada trimestre y después de cualquier cambio importante en el proceso. Mide si todavía se puede presentar una candidatura, si un reclutador puede identificar un enriquecimiento fallido y si, al recuperar el servicio, no se duplica ninguna acción dirigida al candidato. Esos resultados importan más que un porcentaje nominal de disponibilidad.

¿Qué mantiene Kit en funcionamiento y dónde sigue dependiendo de la IA?

Kit separa los datos esenciales de contratación y muchos procesos manuales del enriquecimiento con IA. No promete, en cambio, un sistema de contratación sin conexión ni una conmutación entre proveedores en función de su estado operativo. En la práctica, la continuidad llega hasta aquí: los datos de contratación permanecen guardados mientras la asistencia que depende de modelos falla de forma visible.

La recepción pública de candidaturas guarda los datos del candidato, la candidatura, el consentimiento, el formulario enviado y la etapa inicial en una transacción de base de datos. La extracción del CV no se ejecuta hasta que esa transacción se ha confirmado. Si la extracción falla, la candidatura no desaparece con ella. Los cambios manuales de etapa conservan el estado canónico del pipeline tanto si se originan en la interfaz web como mediante una herramienta MCP. Que el modelo decida llamar a esa herramienta constituye una dependencia distinta.

Los reclutadores pueden crear invitaciones para entrevistas, los candidatos pueden confirmar entrevistas programadas en Kit y los equipos pueden conservar mensajes redactados por personas y plantillas Liquid sin llamar a un modelo. Estas rutas todavía dependen de sistemas como la disponibilidad de calendarios, la integración con Google Meet o Calendly, las tareas en segundo plano y la entrega por SMTP. Sería falso describirlas como totalmente disponibles sin conexión.

En algunos puntos concretos, Kit también ofrece mecanismos de respaldo limitados. Si falla el proveedor o el transporte, la redacción de respuestas con IA puede devolver un texto inicial determinista en el editor. Algunas búsquedas semánticas pasan de los embeddings de Gemini a la búsqueda de texto de PostgreSQL cuando los primeros fallan. Las herramientas de resumen de candidaturas y candidatos serializan registros almacenados en vez de generar prosa dentro de la herramienta. Un modelo conectado puede interpretar esos registros, pero no determina ni conserva su estado. Nuestra guía sobre MCP para la contratación explica esa separación entre el modelo y las herramientas de selección cuyo uso puede solicitar.

También hay límites. Kit no supervisa el estado de los proveedores ni cambia automáticamente entre Gemini, Anthropic y OpenRouter. El cambio a un nivel inferior del modelo se mantiene dentro del proveedor configurado. Los fallos genéricos del chat se muestran como errores en lugar de entrar en un sistema universal de reintentos. La extracción fallida de CV y metacampos puede requerir una recuperación manual, y los embeddings siguen ligados a Gemini aunque el chat utilice otro proveedor. Kit no vuelve a ejecutar todos los enriquecimientos fallidos ni elimina las dependencias de calendarios, SMTP o modelos.

Ese es el criterio que debes aplicar a cualquier ATS diseñado desde el principio para trabajar con IA: cuando la página de estado del modelo se ponga en rojo, los datos de contratación no deberían hacerlo. Mantén las candidaturas y las decisiones como fuente de verdad, el trabajo de IA como derivado y recuperable, y la vía humana bien visible antes de necesitarla.