Sapan Pandya, ingeniero sénior de software y miembro sénior de IEEE – Serie de entrevistas

Sapan Pandya es ingeniero sénior de software y miembro sénior de IEEE, y reside en Nueva Jersey. Cuenta con más de diez años de experiencia en sistemas distribuidos resilientes para transacciones. Su trabajo abarca la integridad de las transacciones, la integración de software con dispositivos físicos, la resolución de problemas en producción y la validación de implementaciones en entornos regulados. Tiene una maestría en Informática por Stevens Institute of Technology y participa en revisiones académicas e investigaciones técnicas.

La investigación de Pandya aborda la ciberseguridad de los quioscos, la IA en el borde y la ingeniería de confiabilidad asistida por IA, mientras que su experiencia en producción orienta su enfoque en las pruebas, los resultados de las transacciones y la rendición de cuentas operativa. En esta entrevista, habla de idempotencia, registros de transacciones contradictorios, incertidumbre en los sistemas de recuperación y los controles necesarios antes de que los agentes de IA puedan actuar sobre infraestructuras de misión crítica. Distingue la experiencia práctica en ingeniería de la investigación realizada mediante análisis bibliográfico y pruebas controladas o sintéticas.

Tu carrera se ha centrado en la confiabilidad del software y los sistemas distribuidos para transacciones. ¿Cómo ha influido esa experiencia en tu comprensión de la confiabilidad y qué desafíos han moldeado tu perspectiva sobre el uso de la IA para gestionar sistemas complejos?

Mi perspectiva ha pasado de preguntarme si un componente funciona a preguntarme si la transacción del cliente se ha completado y puede contabilizarse.

Al principio de mi carrera, gran parte de mi atención se centraba en el comportamiento de las aplicaciones: validar entradas, gestionar respuestas y asegurarme de que la interfaz siguiera el flujo de trabajo previsto. A medida que mis responsabilidades se ampliaron para abarcar la integración de sistemas, la resolución de problemas en producción y la validación de implementaciones, tuve que mirar más allá de los componentes individuales.

Un servicio puede terminar su trabajo mientras otro sigue esperando confirmación. El software puede registrar una operación como exitosa mientras un dispositivo físico no logra ofrecer el resultado esperado. Que cada componente supere las pruebas no demuestra, por sí solo, que la interacción completa vaya a funcionar correctamente.

Esa experiencia ha despertado en mí un interés especial por los límites entre los sistemas. ¿Qué sabe cada componente? ¿Qué da por sentado? ¿Qué ocurre cuando esas suposiciones dejan de ser válidas?

También influye en mi forma de pensar sobre la IA. Puede ser muy útil para ayudar a los ingenieros a reunir pruebas, reconocer patrones e investigar fallos con mayor rapidez. Pero explicar lo que probablemente ocurrió no es lo mismo que verificar lo que realmente ocurrió.

Quiero que la IA reduzca el esfuerzo necesario para investigar un problema sin rebajar el nivel de pruebas exigido para resolverlo.

Has destacado que un código técnicamente correcto no siempre garantiza que las transacciones produzcan los resultados correctos. ¿Podrías contarnos un ejemplo concreto de una transacción que parece fallar por un tiempo de espera agotado, pero que en realidad sí se ha completado? ¿Qué puede salir mal si el sistema vuelve a intentar la operación automáticamente y cómo deberían evitar los ingenieros las transacciones duplicadas?

Pensemos en un pago hipotético de $50. La aplicación envía una solicitud, el servicio de pagos la registra correctamente y la respuesta se pierde antes de llegar a la aplicación.

El cliente ve que se agotó el tiempo de espera, aunque el pago ya se haya efectuado. Si la aplicación envía otra solicitud de pago, podría volver a cobrarle.

Un tiempo de espera agotado indica que la respuesta no llegó a tiempo. No indica si la transacción subyacente se completó correctamente.

Una medida de protección habitual es la idempotencia: permitir que se repita la misma solicitud lógica sin generar otro efecto financiero. La aplicación conserva el identificador de la operación en cada reintento, y el servicio receptor lo reconoce como la solicitud original, no como una compra nueva.

Lo importante no es simplemente adjuntar un identificador. El servicio debe hacer cumplir esa identidad y conservar suficiente información para distinguir una operación completada de otra que sigue en curso. Un identificador no puede proteger una acción posterior que lo ignore.

Si el resultado sigue siendo incierto, el proceso de recuperación debería consultar la transacción existente y conciliar los registros pertinentes, en lugar de crear inmediatamente una transacción de reemplazo.

También limitaría los reintentos y definiría qué ocurre cuando la recuperación automática no permite determinar el resultado. El cliente necesita un estado claro de operación pendiente y una vía para resolverla, no cargos repetidos ni una pantalla de procesamiento interminable.

En los sistemas distribuidos, es posible que una base de datos, un servicio de backend y un quiosco físico comuniquen información contradictoria sobre una misma transacción. ¿Te has encontrado con este tipo de incoherencia en producción y cómo se investigó y resolvió? ¿Qué papel podría desempeñar la IA, si es que tiene alguno, para conciliar esos registros contradictorios?

Sí, investigar incoherencias en el estado de las transacciones ha formado parte de mi trabajo en producción. Para explicar el razonamiento sin hablar de un incidente laboral, usaré un ejemplo hipotético.

Pensemos en una caja de autoservicio genérica. El servicio de pagos registra una compra como exitosa, la impresora indica que aceptó el trabajo de impresión del recibo y, luego, la pantalla muestra un error. Esas observaciones podrían describir distintas etapas de la interacción, en lugar de demostrar que toda la compra falló.

Primero reconstruiría la secuencia con el identificador de la transacción y los registros pertinentes de los servicios y dispositivos. Después determinaría qué demuestra cada observación. Que una impresora acepte un trabajo no necesariamente demuestra que el cliente haya recibido el papel. Que se reciba una solicitud no necesariamente demuestra que se haya aplicado su efecto financiero.

La solución depende de qué etapa haya fallado. Repetir toda la transacción podría ser inadecuado si solo hay que atender la etapa de salida. Si las pruebas disponibles no permiten determinar qué ocurrió, la operación afectada debería permanecer bajo control mientras alguien investiga.

La solución definitiva también debe abordar por qué pudo producirse la inconsistencia, en lugar de limitarse a corregir un registro.

La IA podría ayudar a correlacionar eventos e identificar la información que falta. Le pediría que presentara explicaciones alternativas y las pruebas que respaldan cada una. Debería ayudar a acotar la investigación, no resolver las discrepancias entre registros eligiendo la explicación que parezca más convincente.

A medida que los agentes de IA pasan de diagnosticar incidentes en producción a recomendar o ejecutar acciones de recuperación, ¿qué salvaguardas deberían implementarse antes de que un sistema de IA pueda reintentar, revertir o modificar una transacción? ¿Cómo pueden los controles deterministas, como las claves de idempotencia, los registros de transacciones y los mecanismos de conciliación, evitar que la IA provoque fallos adicionales?

Separaría la propuesta de una acción de su autorización y ejecución.

Un agente de IA podría recomendar reintentar una operación, pero un control independiente debería determinar si está permitido. Debería comprobar el estado actual de la transacción, la identidad de la operación, los permisos del agente y las condiciones en las que esa acción es segura.

Esa comprobación debe realizarse cuando se ejecuta la acción, no solo cuando el modelo examinó el incidente por primera vez. Mientras tanto, otro proceso podría haber completado la transacción.

Las herramientas disponibles para el agente también deberían tener un alcance limitado. Tener permiso para consultar el estado de una transacción no equivale a tener permiso para revertir un pago o modificar un registro financiero. El agente no debería poder ampliar sus propios permisos porque su solución preferida requiera más acceso.

La idempotencia limita los efectos duplicados. Los registros conservan el historial necesario para investigar. La conciliación verifica que los registros pertinentes coincidan. Ninguno de estos elementos, por sí solo, determina si una acción propuesta es adecuada.

También registraría las pruebas utilizadas, la recomendación, la decisión de autorización y el resultado efectivo. Así sería posible revisar la intervención posteriormente.

Estos controles deberían aplicarse mediante software comprobable que funcione fuera del modelo. Las instrucciones que indican a un agente que actúe con cuidado son una guía útil, pero no constituyen un mecanismo de autorización.

Pensemos en un escenario en el que un sistema de supervisión con IA detecta un aparente fallo de transacción y recomienda revertir automáticamente la operación. Si la transacción se completó, pero la confirmación se retrasó, esa intervención podría generar un nuevo problema. ¿Cómo deberían diseñar los equipos de ingeniería sistemas de recuperación basados en IA que reconozcan la incertidumbre y eviten tomar medidas correctivas a partir de información incompleta?

El sistema necesita un estado genuino de «resultado desconocido». De lo contrario, es probable que convierta la falta de información en una decisión errónea de que hubo un fallo.

Una confirmación retrasada es motivo para investigar, no necesariamente para revertir una transacción. Una reversión es otra operación financiera, con sus propias consecuencias. Debe estar justificada por motivos establecidos de forma independiente y contar con la autorización correspondiente.

Separaría la respuesta en dos vías. La vía de investigación puede consultar el estado, recopilar los eventos que faltan, comparar registros y avisar al equipo responsable. La vía de acciones financieras permanece bloqueada hasta que se cumplan las condiciones necesarias.

Así se evita que la puntuación de confianza de una IA sustituya las pruebas de la transacción. Un modelo puede estar muy convencido de una explicación basada en información incompleta.

También debe establecerse un punto de escalamiento. Dejar una transacción pendiente indefinidamente no es un resultado satisfactorio para el cliente. Alguien debe hacerse cargo del caso sin resolver y contar con suficiente contexto para determinar el siguiente paso seguro.

Por lo tanto, el proceso de recuperación debería poder decir tanto «Todavía no puedo justificar un cambio en esta transacción» como «Esto es lo que debe hacerse para resolverla».

Reconocer la incertidumbre solo es útil si el sistema dispone de una forma práctica de gestionarla.

Una de las principales preguntas en torno a la IA autónoma es determinar cuándo sigue siendo esencial la aprobación humana. ¿Qué medidas de recuperación en producción cree que debería poder ejecutar la IA de forma independiente y cuáles deberían requerir siempre autorización humana? ¿Cómo deberían establecer las organizaciones estos límites cuando están en juego las transacciones financieras, el cumplimiento normativo o la confianza de los clientes?

Yo fijaría el límite en función de las consecuencias de equivocarse, no de si una acción lleva la etiqueta «IA» o no.

Una opción razonable para empezar es permitir investigaciones de solo lectura, siempre que el agente solo pueda acceder a información autorizada. Puede recopilar registros de diagnóstico, agrupar alertas relacionadas y preparar un resumen del incidente sin tener permiso para modificar la transacción subyacente.

Algunos procedimientos de recuperación predefinidos también pueden ser aptos para la automatización cuando sus condiciones se verifican de forma independiente y sus efectos son limitados.

Exigiría autorización humana si la intervención propuesta se sale de un procedimiento aprobado, si hay discrepancias entre los registros y el resultado financiero sigue sin resolverse, o si la acción modificara los controles de seguridad o los propios permisos del agente. Un agente no debería autorizar por sí mismo ese tipo de decisiones.

Eso no significa que una persona deba aprobar todas las operaciones financieras rutinarias. El procesamiento basado en reglas establecidas es distinto de permitir que un modelo improvise una corrección durante un incidente.

La revisión humana también debe ser sustantiva. La pantalla de aprobación debería mostrar las pruebas que respaldan la propuesta, la incertidumbre restante, el efecto previsto y las alternativas disponibles. Pedirle a alguien que apruebe un párrafo tajante sin ese contexto aporta poca protección.

Estos límites deberían acordarse antes de la implementación. Una interrupción del servicio no es el momento adecuado para decidir cuánta autoridad debería tener un sistema automatizado.

Ha trabajado extensamente en sistemas de backend tolerantes a fallos, herramientas de observabilidad e integraciones entre servicios de software y hardware físico. ¿Qué tipo de telemetría de producción y pruebas necesitaría un agente de IA para diagnosticar un incidente de forma fiable? ¿Cómo pueden los equipos de ingeniería distinguir entre recomendaciones útiles generadas por IA y conclusiones plausibles, pero incorrectas, que podrían agravar una interrupción del servicio?

Empezaría por pruebas que permitan seguir la operación del cliente a través de los sistemas implicados: identificadores de transacciones, eventos de los servicios, cambios persistentes de estado, respuestas de los dispositivos y fallos de comunicación.

También son importantes las versiones del software y los cambios de configuración. Si un fallo comienza después de una publicación, eso ofrece una pista útil para la investigación, pero la coincidencia temporal por sí sola no demuestra una relación causal.

El agente también debe comprender los límites de las pruebas. Los registros pueden estar incompletos, llegar con retraso y tener marcas de tiempo discordantes. La ausencia de una confirmación no demuestra que no se haya realizado ninguna operación.

Un diagnóstico útil debería separar las observaciones de las interpretaciones. «El cliente registró un tiempo de espera agotado» es una observación. «El backend no estaba disponible» es una explicación que requiere más pruebas.

Esperaría que una recomendación identificara los registros en que se basa, explicara qué aspectos siguen sin conocerse y especificara qué comprobación adicional permitiría confirmar o refutar su conclusión.

A continuación, los ingenieros deberían verificar las recomendaciones de importancia consultando los registros originales, en lugar de confiar únicamente en el resumen del agente. Esto es especialmente importante cuando un resumen condensa un historial de eventos extenso o contradictorio.

El criterio que aplicaría es sencillo: ¿puede otro ingeniero seguir las pruebas y llegar a una conclusión defendible? Si la explicación no resiste esa comprobación, todavía no está lista para justificar un cambio en producción.

En su investigación publicada sobre la resiliencia frente al ransomware de los quioscos de lotería y apuestas, evaluó un marco de seguridad asistido por IA en un entorno sintético que simulaba 500 quioscos. ¿Cuáles fueron los hallazgos más importantes y qué limitaciones deberían tener en cuenta los lectores al interpretarlos? ¿Qué validación adicional sería necesaria antes de aplicar la arquitectura propuesta a un entorno de producción real?

Quería examinar la resiliencia más allá de la detección: cómo un entorno de terminales podía limitar un ataque, reconocerlo y recuperarse, preservando al mismo tiempo las pruebas de lo ocurrido.

El Resilient Security Framework resultante combinó controles preventivos, detección de anomalías asistida por IA y mecanismos definidos de respuesta y recuperación. El componente de IA se ocupaba de detectar comportamientos sospechosos. No se trató de un experimento en el que se permitiera a un agente basado en un modelo de lenguaje modificar transacciones financieras de forma independiente.

La evaluación se llevó a cabo en un entorno sintético que representaba 500 quioscos durante una simulación de 72 horas, con emulaciones de comportamiento de ataques de ransomware, y no mediante una implementación en 500 terminales físicos.

En comparación con la línea de base del estudio, que utilizó únicamente antivirus, el tiempo medio de detección bajó de 52 a 31 minutos y el tiempo medio de recuperación, de 120 a 56 minutos.

Estos son los resultados del marco combinado en las condiciones experimentales. No deben atribuirse únicamente a la IA ni considerarse garantías de rendimiento en un entorno operativo real. Un hallazgo relevante fue que la detección temprana, por sí sola, no produjo la misma mejora en la recuperación. El diseño de la contención y la recuperación también fue importante.

Las limitaciones son importantes. Las cargas de trabajo simuladas, las condiciones de red, los comportamientos de los ataques y las defensas de referencia no representan todos los entornos operativos. Sería necesario realizar nuevas validaciones para distintos dispositivos y aplicaciones.

Antes de utilizarlo en producción, querría probarlo en hardware representativo, someterlo a una evaluación de seguridad independiente, realizar evaluaciones de mayor duración y medir cuidadosamente las falsas alarmas y la sobrecarga de procesamiento.

También probaría el proceso de recuperación frente a la actividad legítima de las transacciones. No basta con restaurar una imagen de software funcional si el proceso pierde la información necesaria para contabilizar las transacciones completadas.

El estudio sienta las bases para realizar más pruebas. Demostrar un comportamiento seguro en un entorno operativo real es un paso distinto.

Tu perspectiva combina años de experiencia en ingeniería de producción con investigación académica sobre la fiabilidad del software y la seguridad impulsada por IA. ¿Puedes distinguir entre los mecanismos de fiabilidad que has implementado u operado personalmente en sistemas de producción reales y los enfoques que has explorado mediante investigaciones o pruebas simuladas? ¿Qué capacidades de recuperación impulsadas por IA consideras que ya son prácticas hoy y cuáles siguen siendo, en gran medida, experimentales?

Mi trabajo en producción ha incluido desarrollo e integración de software, validación de transacciones, resolución de problemas, pruebas y validación de versiones.

La investigación que he publicado es una parte distinta de mi trabajo, y cada estudio debe entenderse teniendo en cuenta los métodos y las limitaciones que declara.

El artículo sobre ransomware evalúa un marco de seguridad propuesto en un entorno de pruebas sintético. Mi artículo sobre IA en el borde es un análisis basado en bibliografía sobre la inteligencia integrada en los dispositivos y su posible aplicación a los terminales de transacciones. Mi artículo de IEEE FeedForward examina una arquitectura de fiabilidad asistida por IA mediante una simulación controlada, que incluye supervisión, escalamiento y mecanismos alternativos.

Ninguna de esas publicaciones debe interpretarse como prueba de que haya desplegado un agente autónomo de IA con autoridad sobre transacciones financieras reales.

Para un uso práctico, daría prioridad a herramientas de asistencia que los ingenieros puedan inspeccionar: resúmenes de incidentes vinculados a los registros de origen, correlaciones entre alertas y comprobaciones de diagnóstico sugeridas. Aun así, su utilidad debe medirse en el entorno en el que vayan a operar.

El problema más difícil es la recuperación de propósito general, en la que un modelo elige y ejecuta cambios en circunstancias imprevistas. Eso exige un nivel de evidencia mucho más alto que una sugerencia de diagnóstico útil.

Considero que mi experiencia en producción y mi investigación se complementan: la primera establece cuáles son los problemas operativos que conozco, mientras que la segunda explora enfoques que aún deben demostrar su valía mediante la validación.

De cara al futuro, a medida que los agentes de IA sean más capaces de detectar anomalías, diagnosticar fallos y coordinar la recuperación en sistemas distribuidos, ¿cómo imaginas que evolucionará la relación entre los sistemas autónomos y los ingenieros humanos? ¿Qué salvaguardas técnicas, pruebas operativas y mecanismos de rendición de cuentas serían necesarios para que las organizaciones pudieran confiar en otorgar a la IA más autoridad sobre infraestructuras de producción esenciales para su misión?

Espero que la IA asuma una parte cada vez mayor del trabajo necesario para reconstruir lo ocurrido durante un incidente. Los ingenieros podrían empezar con una cronología útil, los componentes afectados, explicaciones posibles y las pruebas que faltan, en lugar de dedicar tanto tiempo a recopilar esa información manualmente.

Así, las personas tendrían más tiempo para tomar decisiones que requieren comprender las obligaciones del sistema y las consecuencias de modificarlo.

Ampliaría gradualmente la autoridad para ejecutar acciones. Al principio, un agente podría operar en modo sombra y generar recomendaciones sin llevarlas a cabo. Los equipos podrían comparar esas recomendaciones con los resultados revisados y probar cómo se comporta el agente cuando la información es incompleta, contradictoria o está desactualizada.

La evaluación debería incluir intervenciones incorrectas, problemas no detectados, escalaciones innecesarias y la recuperación de los propios errores del agente. Una recomendación rápida no sirve de nada si orienta al equipo de respuesta en la dirección equivocada.

La autoridad ampliada también debería seguir estando sujeta a condiciones. Una actualización del modelo o un cambio importante en el sistema pueden invalidar las pruebas anteriores. Los equipos necesitan una forma de reducir o retirar los permisos del agente cuando su comportamiento deje de cumplir el estándar requerido.

La automatización no elimina la responsabilidad humana. Alguien debe hacerse cargo de las reglas operativas, las pruebas necesarias para autorizar un cambio y el proceso para investigar los fallos.

Creo que los ingenieros dedicarán menos tiempo a recopilar información y más a definir, probar y mantener las condiciones que justifican las acciones automatizadas.

Gracias por esta excelente entrevista. Los lectores que deseen seguir su trabajo sobre la fiabilidad de las transacciones distribuidas y la recuperación responsable asistida por IA pueden ponerse en contacto con Sapan Pandya.