Una función de IA integrada en una aplicación PHP puede tardar demasiado, no estar disponible o devolver un resultado que no sirve para el proceso. El problema no se resuelve tratando cada respuesta como válida ni repitiendo la petición indefinidamente: ambas decisiones pueden comprometer la experiencia, los datos y los costes. Un fallback para integración de IA en PHP define qué hará el sistema cuando la dependencia falle y qué operaciones no deben continuar sin una respuesta aceptable.
La alternativa correcta depende del impacto de la función. Una sugerencia de texto puede omitirse temporalmente; una decisión que afecta a un pago, un permiso o una actualización de datos no debería ejecutarse a partir de información incompleta o supuesta. El objetivo es mantener un comportamiento predecible, no ocultar todos los errores.
Definir qué se considera un fallo
Antes de implementar alternativas, especifica las condiciones que hacen que una respuesta no sea utilizable. Separar los casos facilita elegir una política y medir si está funcionando:
- Timeout: la solicitud supera el límite de espera de la aplicación.
- Indisponibilidad o error de transporte: la conexión falla o el proveedor responde con un error.
- Respuesta vacía: la llamada termina, pero no contiene el contenido esperado.
- Formato inválido: el resultado no puede analizarse o incumple el esquema requerido, por ejemplo, JSON con campos ausentes.
- Resultado no aceptable: la salida es legible, pero no pasa reglas de negocio, validaciones o criterios de seguridad.
No conviene equiparar una respuesta técnicamente correcta con una decisión válida. Si la aplicación espera una categoría de un conjunto cerrado, debe verificar que el valor pertenece a ese conjunto. Si espera campos obligatorios, debe validarlos antes de pasarlos a otro componente. Las comprobaciones deterministas deben ejecutarse en el código PHP; no se delegan de nuevo al mismo modelo.
Limitar la espera y los reintentos
Establece un timeout acorde con la operación y con el tiempo total que el usuario o el proceso puede esperar. Considera también los límites del servidor web, la cola y cualquier cliente HTTP intermedio: un timeout local que excede el límite de la petición no aporta control real. En una tarea en segundo plano puede aceptarse otra ventana de espera, siempre que exista una política explícita para los trabajos pendientes.
Los reintentos deben ser acotados y aplicarse sólo a fallos que puedan ser transitorios. Una interrupción de red puede justificar un intento adicional; una respuesta que incumple el esquema normalmente requiere validación, fallback o revisión, no repetir a ciegas. Limita el número de intentos y el tiempo total. Si se usa una espera incremental, fija también un máximo.
Ten en cuenta que repetir una llamada puede duplicar consumo o efectos. Evita reintentos automáticos sin límite y revisa si la operación es idempotente. Una generación de texto sin efectos secundarios no equivale a una acción que crea un pedido o envía una notificación. Para operaciones sensibles, separa la generación de una propuesta de su ejecución y exige controles propios para esta última.
Elegir una alternativa según el impacto
Un fallback no es una respuesta genérica para todos los fallos. Debe preservar las reglas de negocio y comunicar con claridad qué puede hacer la aplicación:
- Degradar: si la IA aporta comodidad, permite continuar sin esa función. Por ejemplo, presentar el formulario convencional cuando no se genera una sugerencia.
- Aplazar: si el resultado puede producirse después, guarda el trabajo con un estado pendiente y permite reintentarlo mediante una cola, con límites y seguimiento.
- Solicitar revisión: si hace falta criterio humano, muestra una propuesta como borrador o deriva el caso a una persona. No presentes una salida no validada como decisión final.
- Rechazar o detener: si no se puede verificar una condición necesaria para operar, impide la acción y explica cómo continuar o solicitar ayuda.
La decisión debe basarse en el riesgo de actuar incorrectamente, no sólo en el coste de interrumpir. Un buscador con sugerencias puede seguir usando la consulta original. En cambio, un flujo que modifica datos de clientes no debería completar campos ausentes mediante conjeturas. Si la salida de IA influye en una decisión de negocio, conserva una ruta manual o una regla determinista cuando sea viable.
Proteger la integridad de los procesos
Trata la respuesta del modelo como entrada externa: analiza su estructura, valida cada valor y limita qué operaciones puede iniciar. No la insertes directamente en consultas SQL, comandos, HTML o instrucciones para otros sistemas. Usa consultas parametrizadas, codificación apropiada y listas permitidas, además de las comprobaciones específicas del dominio.
Define una frontera entre sugerir y ejecutar. Por ejemplo, la IA puede proponer una clasificación; el código valida que sea admisible y la política del producto decide si se aplica automáticamente o queda pendiente. Cuando falte un dato requerido, la alternativa segura suele ser pedirlo, dejar el caso incompleto o detener el proceso, no inventarlo. El comportamiento ante fallos también debe respetar permisos, validaciones y reglas de autorización habituales.
Registrar fallos sin guardar información innecesaria
Los registros deben ayudar a diagnosticar sin convertirse en una copia de las conversaciones. Guarda eventos técnicos como la operación, el tipo de fallo, la duración, el número de intentos, el resultado de la validación y un identificador de correlación. Añade información suficiente para distinguir, por ejemplo, un timeout de un JSON mal formado, pero evita registrar por defecto prompts completos, respuestas, credenciales o datos personales.
Si se requiere conservar contenido para una revisión o auditoría, define propósito, acceso, retención y medidas de protección antes de hacerlo. En métricas, sigue la frecuencia de timeouts, respuestas inválidas, fallbacks y trabajos pendientes, además de la latencia y los reintentos. Un aumento puede señalar un problema operativo o un cambio en el comportamiento de la salida. Las métricas permiten detectar tendencias; no sustituyen la revisión del caso ni demuestran por sí solas que una respuesta sea correcta.
Probar escenarios y acordar criterios
Prueba la integración con respuestas controladas y verifica tanto el resultado visible como los efectos en el sistema. Incluye latencia elevada, interrupción de conexión, respuesta vacía, formato inválido, dato fuera de las reglas y recuperación tras un fallo. Comprueba que no se ejecuten acciones duplicadas, que los reintentos respeten sus límites y que los registros no revelen contenido sensible. También prueba qué sucede cuando una tarea queda pendiente o requiere intervención.
Antes de poner una función en producción, acuerda estas decisiones con producto y tecnología:
- ¿La función es esencial para completar la operación o sólo mejora la experiencia?
- ¿Qué tiempo de espera total resulta aceptable en cada canal?
- ¿Qué fallos permiten un reintento y cuántos se permiten?
- ¿Cuál es la alternativa segura: continuar sin IA, aplazar, revisión humana o detener?
- ¿Qué validaciones deben pasar antes de utilizar la respuesta?
- ¿Qué datos se registran, quién puede acceder y cuánto tiempo se conservan?
- ¿Cómo se alerta al equipo y quién resuelve los casos pendientes?
Una política útil permite degradar funciones accesorias y detener operaciones que dependen de datos no verificados. Si no se puede explicar con precisión qué ocurre ante una respuesta tardía, inválida o ausente, la integración aún no tiene un fallback operativo. Documenta esas reglas junto al flujo y vuelve a probarlas cuando cambien el producto, las validaciones o la forma de consumir el servicio.
