Sapan Pandya, engenheiro de software sênior e membro sênior do IEEE – série de entrevistas

Sapan Pandya é engenheiro de software sênior e membro sênior do IEEE, radicado em Nova Jersey, com mais de dez anos de experiência em sistemas distribuídos resilientes de transações. Seu trabalho abrange a integridade de transações, a integração entre software e dispositivos físicos, a solução de problemas em produção e a validação de implantações em ambientes regulamentados. Ele tem mestrado em Ciência da Computação pelo Stevens Institute of Technology e contribui para a revisão acadêmica e a pesquisa técnica.

A pesquisa de Pandya explora a cibersegurança de quiosques, a IA de borda e a engenharia de confiabilidade assistida por IA, enquanto sua experiência em produção orienta seu foco em evidências, resultados de transações e responsabilidade operacional. Nesta entrevista, ele fala sobre idempotência, registros de transações conflitantes, incertezas em sistemas de recuperação e os controles necessários antes que agentes de IA possam atuar em infraestruturas de missão crítica. Ele distingue a experiência prática em engenharia da pesquisa realizada por meio de análise da literatura e testes controlados ou sintéticos.

Sua carreira tem se concentrado na confiabilidade de software e em sistemas distribuídos de transações. Como essa experiência moldou sua compreensão da confiabilidade e quais desafios influenciaram sua perspectiva sobre o uso da IA para gerenciar sistemas complexos?

Minha perspectiva mudou: deixei de perguntar se um componente funciona e passei a perguntar se a transação do cliente foi concluída e pode ser contabilizada.

No início da minha carreira, grande parte da minha atenção estava voltada para o comportamento dos aplicativos: validar entradas, tratar respostas e garantir que a interface seguisse o fluxo de trabalho previsto. À medida que minhas responsabilidades se ampliaram para incluir integração de sistemas, solução de problemas em produção e validação de implantações, precisei olhar além dos componentes individuais.

Um serviço pode concluir seu trabalho enquanto outro ainda aguarda confirmação. O software pode registrar uma operação como bem-sucedida, mesmo que um dispositivo físico não forneça o resultado esperado. O fato de cada componente passar nos testes não basta, por si só, para garantir que a interação completa funcionará corretamente.

Essa experiência despertou meu interesse particular pelas fronteiras entre os sistemas. O que cada componente sabe? O que está presumindo? O que acontece quando essas suposições deixam de ser válidas?

Isso também influencia minha maneira de pensar sobre IA. Ajudar engenheiros a reunir evidências, reconhecer padrões e investigar falhas com mais rapidez tem um valor real. Mas uma explicação do que provavelmente aconteceu é diferente de um relato verificado do que de fato aconteceu.

Quero que a IA reduza o esforço necessário para investigar um problema sem diminuir o padrão de evidências exigido para resolvê-lo.

Você ressaltou que um código tecnicamente correto nem sempre garante resultados corretos nas transações. Pode nos dar um exemplo concreto em que uma transação parece falhar por causa de um tempo limite, mas, na verdade, foi concluída? O que pode dar errado quando o sistema tenta executar a operação novamente de forma automática, e como os engenheiros devem evitar transações duplicadas?

Considere um pagamento hipotético de US$ 50. O aplicativo envia uma solicitação, o serviço de pagamento a registra com sucesso e a resposta se perde antes de chegar ao aplicativo.

O cliente vê uma mensagem de tempo limite, embora o pagamento já tenha sido processado. Se o aplicativo enviar uma nova solicitação de pagamento, poderá cobrar o cliente novamente.

Um tempo limite informa que a resposta não chegou a tempo. Não informa se a transação subjacente foi concluída com sucesso.

Uma medida de proteção comum é a idempotência: permitir que a mesma solicitação lógica seja repetida sem gerar outro efeito financeiro. O aplicativo mantém o mesmo identificador de operação durante as novas tentativas, e o serviço que recebe a solicitação o reconhece como a solicitação original, e não como uma nova compra.

O importante não é simplesmente anexar um identificador. O serviço precisa garantir que essa identificação seja respeitada e preservar informações suficientes para distinguir uma operação concluída de outra ainda em andamento. Um identificador não protege uma ação subsequente que o ignora.

Quando o resultado continua incerto, o processo de recuperação deve verificar a transação existente e reconciliar os registros pertinentes, em vez de criar imediatamente uma substituta.

Eu também limitaria o número de novas tentativas e definiria o que fazer quando a recuperação automática não conseguir determinar o resultado. O cliente precisa de um status claro de pendência e de um caminho para resolver a situação, não de cobranças repetidas nem de uma tela de processamento interminável.

Em sistemas distribuídos, um banco de dados, um serviço de backend e um quiosque físico podem apresentar informações conflitantes sobre a mesma transação. Você já se deparou com esse tipo de inconsistência em produção? Como ela foi investigada e resolvida? Que papel a IA poderia desempenhar, se algum, na reconciliação desses registros conflitantes?

Sim, investigar inconsistências no estado das transações fez parte do meu trabalho em produção. Para explicar o raciocínio sem falar de um incidente ocorrido no trabalho, vou usar um exemplo hipotético.

Considere um caixa genérico de autoatendimento. O serviço de pagamento registra uma compra bem-sucedida, a impressora informa que aceitou a solicitação de impressão do recibo e, em seguida, a tela exibe um erro. Essas observações podem descrever etapas diferentes da interação, em vez de provar que a compra inteira falhou.

Primeiro, eu reconstruiria a sequência usando o identificador da transação e os registros pertinentes dos serviços e dispositivos. Depois, determinaria o que cada observação comprova. O fato de uma impressora aceitar uma solicitação de impressão não significa necessariamente que o recibo chegou ao cliente. O recebimento de uma solicitação não significa necessariamente que seu efeito financeiro foi efetivado.

A solução depende da etapa em que ocorreu a falha. Repetir a transação inteira pode ser inadequado quando apenas a etapa de saída precisa de atenção. Se as evidências disponíveis não permitirem determinar o que aconteceu, a operação afetada deve permanecer sob controle enquanto alguém investiga.

A correção definitiva também precisa abordar por que essa inconsistência pôde ocorrer, em vez de simplesmente corrigir um registro.

A IA poderia ajudar a correlacionar eventos e identificar informações ausentes. Eu pediria que apresentasse explicações alternativas e as evidências que sustentam cada uma. Ela deve ajudar a delimitar a investigação, não resolver registros conflitantes escolhendo a explicação que pareça mais convincente.

À medida que os agentes de IA passam de diagnosticar incidentes em produção a recomendar ou executar ações de recuperação, quais salvaguardas devem estar em vigor antes que um sistema de IA possa tentar novamente, estornar ou modificar uma transação? Como controles determinísticos, como chaves de idempotência, registros de transações e mecanismos de conciliação, podem impedir que a IA provoque falhas adicionais?

Eu separaria a proposta de uma ação de sua autorização e execução.

Um agente de IA poderia recomendar uma nova tentativa, mas um controle separado deveria determinar se ela é permitida. Esse controle deveria verificar o estado atual da transação, a identidade da operação, as permissões do agente e as condições em que a ação é segura.

Essa verificação precisa ocorrer no momento da execução da ação, não apenas quando o modelo analisou o incidente pela primeira vez. Enquanto isso, outro processo pode ter concluído a transação.

As ferramentas disponíveis para o agente também devem ter escopo restrito. A permissão para consultar o status de uma transação é diferente da permissão para estornar um pagamento ou modificar um registro financeiro. O agente não deve poder ampliar a própria autoridade porque a solução que prefere exige mais acesso.

A idempotência limita os efeitos duplicados. Os registros preservam o histórico necessário à investigação. A conciliação verifica se os registros pertinentes estão de acordo. Nenhum desses elementos, por si só, determina se uma ação proposta é apropriada.

Eu também registraria as evidências utilizadas, a recomendação, a decisão de autorização e o resultado efetivo. Isso permite analisar a intervenção posteriormente.

Esses controles devem ser aplicados por software testável, fora do modelo. Instruções que orientam um agente a agir com cuidado são úteis, mas não constituem um mecanismo de autorização.

Considere um cenário em que um sistema de monitoramento com IA detecta uma aparente falha em uma transação e recomenda estornar a operação automaticamente. Se a transação tiver sido concluída, mas a confirmação estiver atrasada, essa intervenção poderá criar um novo problema. Como as equipes de engenharia devem projetar sistemas de recuperação baseados em IA para reconhecer a incerteza e evitar ações corretivas fundamentadas em informações incompletas?

O sistema precisa ter um estado verdadeiro de “resultado desconhecido”. Caso contrário, provavelmente transformará a falta de informações em uma decisão incorreta de que houve falha.

Uma confirmação atrasada é motivo para investigar, não necessariamente para estornar uma transação. Um estorno é outra operação financeira, com consequências próprias. Ele exige uma justificativa estabelecida de forma independente e a autorização apropriada.

Eu dividiria a resposta em dois caminhos. O caminho investigativo pode consultar o status, coletar eventos ausentes, comparar registros e notificar a equipe responsável. O caminho da ação financeira permanece bloqueado até que suas condições sejam atendidas.

Isso impede que uma pontuação de confiança da IA substitua as evidências da transação. Um modelo pode ter muita confiança em uma explicação construída com base em informações incompletas.

Também é necessário definir um ponto de escalonamento. Manter uma transação pendente indefinidamente não é um resultado satisfatório para o cliente. Alguém deve ser responsável pelo caso não resolvido e dispor de contexto suficiente para determinar a próxima etapa segura.

Por isso, o processo de recuperação deve ser capaz de dizer tanto “Ainda não posso justificar a alteração desta transação” quanto “Veja o que precisa ser feito para resolvê-la”.

Reconhecer a incerteza só é útil quando o sistema tem uma maneira prática de lidar com ela.

Uma das principais questões em torno da IA autônoma é determinar quando a aprovação humana continua sendo essencial. Na sua opinião, quais ações de recuperação em produção a IA deveria ter permissão para executar de forma independente e quais deveriam sempre exigir autorização humana? Como as organizações deveriam estabelecer esses limites quando estão em jogo transações financeiras, conformidade regulatória ou a confiança dos clientes?

Eu definiria os limites com base nas consequências de um erro, e não no fato de uma ação ser rotulada como “IA”.

Uma investigação somente para leitura é um ponto de partida razoável, desde que o agente só possa acessar informações autorizadas. Ele pode reunir registros de diagnóstico, agrupar alertas relacionados e preparar um resumo do incidente sem ter permissão para alterar a transação subjacente.

Alguns procedimentos de recuperação predefinidos também podem ser adequados para automação quando suas condições são verificadas de forma independente e seus efeitos são limitados.

Eu exigiria autorização humana quando uma intervenção proposta estiver fora de um procedimento aprovado, quando houver conflito entre os registros e o resultado financeiro continuar indefinido, ou quando a ação alterar os controles de segurança ou as próprias permissões do agente. Essas são decisões que um agente não deveria autorizar por conta própria.

Isso não significa que toda operação financeira rotineira exija a aprovação de uma pessoa. O processamento estabelecido com base em regras é diferente de permitir que um modelo invente uma correção durante um incidente.

A análise humana também precisa ser significativa. Uma tela de aprovação deve mostrar as evidências que a fundamentam, as incertezas restantes, o efeito esperado e as alternativas disponíveis. Pedir a alguém que aprove um parágrafo categórico sem esse contexto oferece pouca proteção.

Esses limites devem ser acordados antes da implantação. Uma interrupção não é o momento certo para decidir quanta autoridade um sistema automatizado deve ter.

Você trabalhou extensivamente com sistemas de back-end tolerantes a falhas, ferramentas de observabilidade e integrações entre serviços de software e hardware físico. De que tipos de telemetria e evidências de produção um agente de IA precisaria para diagnosticar um incidente com confiabilidade? Como as equipes de engenharia podem distinguir recomendações úteis geradas por IA de conclusões plausíveis, porém incorretas, que poderiam agravar uma interrupção?

Eu começaria por evidências que conectem a operação do cliente entre os sistemas envolvidos: identificadores de transação, eventos de serviço, alterações persistentes de estado, respostas dos dispositivos e falhas de comunicação.

As versões do software e as alterações de configuração também são importantes. Uma falha que começa após uma versão nova oferece uma pista útil a quem investiga, mas a coincidência temporal, por si só, não comprova uma relação de causa e efeito.

O agente também precisa compreender os limites das evidências. Os registros podem estar incompletos, chegar com atraso e apresentar divergências entre os relógios. A ausência de uma confirmação não equivale à prova de que nenhuma operação ocorreu.

Um diagnóstico útil deve separar observações de interpretações. “O cliente registrou um tempo limite excedido” é uma observação. “O back-end estava indisponível” é uma explicação que precisa de mais evidências.

Eu esperaria que uma recomendação identificasse os registros que a embasam, explicasse o que ainda é desconhecido e especificasse qual verificação adicional confirmaria ou refutaria sua conclusão.

Em seguida, os engenheiros devem verificar as recomendações com consequências importantes consultando os registros originais, em vez de confiar apenas no resumo do agente. Isso é especialmente importante quando um resumo condensa um histórico longo ou contraditório de eventos.

O critério que eu adotaria é simples: outro engenheiro consegue acompanhar as evidências e chegar a uma conclusão defensável? Se a explicação não passar por essa verificação, ainda não está pronta para orientar uma alteração em produção.

Na sua pesquisa publicada sobre resiliência contra ransomware em quiosques de loteria e apostas, você avaliou uma estrutura de segurança assistida por IA usando um ambiente sintético que simulava 500 quiosques. Quais foram as descobertas mais importantes e que limitações os leitores devem considerar ao interpretar esses resultados? Que validações adicionais seriam necessárias antes de aplicar a arquitetura proposta em um ambiente de produção real?

Eu queria analisar a resiliência para além da detecção: como um ambiente de terminais poderia limitar um ataque, reconhecê-lo e se recuperar, preservando as evidências do que aconteceu.

A Resilient Security Framework resultante combinou controles preventivos, detecção de anomalias assistida por IA e mecanismos definidos de resposta e recuperação. O componente de IA se destinava à detecção de comportamentos suspeitos. Não se tratou de um experimento que permitisse a um agente baseado em modelo de linguagem alterar transações financeiras de forma independente.

A avaliação usou um ambiente sintético que representava 500 quiosques ao longo de uma simulação de 72 horas, com emulações comportamentais de ataques de ransomware, em vez de uma implantação em 500 terminais físicos.

Em comparação com a linha de base do estudo, que usava apenas antivírus, o tempo médio de detecção caiu de 52 para 31 minutos, e o tempo médio de recuperação caiu de 120 para 56 minutos.

Esses são os resultados da estrutura combinada nas condições experimentais. Eles não devem ser atribuídos exclusivamente à IA nem tratados como garantias de desempenho em um ambiente real. Uma constatação relevante foi que a detecção mais precoce, por si só, não proporcionou a mesma melhoria na recuperação. O projeto de contenção e recuperação também foi importante.

As limitações são importantes. As cargas de trabalho simuladas, as condições de rede, os comportamentos dos ataques e as defesas de referência não representam todos os ambientes operacionais. Diferentes dispositivos e aplicações exigiriam novas validações.

Antes de usar a solução em produção, eu gostaria de realizar testes em hardware representativo, avaliações de segurança independentes, avaliações mais prolongadas e medições cuidadosas de alarmes falsos e sobrecarga de processamento.

Eu também testaria o processo de recuperação diante de atividades legítimas de transação. Restaurar uma imagem de software funcional não basta se o processo perder as informações necessárias para contabilizar as transações concluídas.

O estudo oferece uma base para testes adicionais. Demonstrar um comportamento seguro em um ambiente operacional real é uma etapa distinta.

Sua perspectiva combina anos de experiência em engenharia de produção com pesquisa acadêmica sobre confiabilidade de software e segurança impulsionada por IA. Você pode distinguir os mecanismos de confiabilidade que implementou pessoalmente ou operou em sistemas de produção ativos das abordagens que explorou por meio de pesquisas ou testes simulados? Quais recursos de recuperação impulsionados por IA você considera viáveis na prática hoje e quais continuam sendo, em grande parte, experimentais?

Meu trabalho em produção incluiu desenvolvimento e integração de software, validação de transações, solução de problemas, testes e validação de versões.

Minha pesquisa publicada é uma parte distinta do meu trabalho, e cada estudo deve ser entendido à luz dos métodos e das limitações que declara.

O artigo sobre ransomware avalia uma estrutura de segurança proposta em um ambiente de testes sintético. Meu artigo sobre IA de borda é uma análise baseada na literatura sobre inteligência no próprio dispositivo e suas possíveis aplicações a terminais de transação. Meu artigo para o IEEE FeedForward examina uma arquitetura de confiabilidade assistida por IA por meio de simulação controlada, incluindo monitoramento, escalonamento e comportamento de contingência.

Nenhuma dessas publicações deve ser interpretada como prova de que implementei um agente autônomo de IA com autoridade sobre transações financeiras reais.

Para uso prático, eu priorizaria recursos de assistência que os engenheiros possam inspecionar: resumos de incidentes vinculados aos registros de origem, correlações entre alertas e verificações de diagnóstico sugeridas. Ainda assim, sua utilidade precisa ser medida no ambiente em que serão utilizados.

O desafio maior é a recuperação de escopo aberto, em que um modelo escolhe e executa alterações em condições imprevistas. Isso exige um padrão de evidências muito mais rigoroso do que uma sugestão útil de diagnóstico.

Vejo minha experiência em produção e minha pesquisa como complementares: uma estabelece os problemas operacionais que conheço, enquanto a outra explora abordagens que ainda precisam comprovar seu valor por meio de validação.

Olhando para o futuro, à medida que os agentes de IA se tornam mais capazes de detectar anomalias, diagnosticar falhas e coordenar a recuperação em sistemas distribuídos, como você imagina que evoluirá a relação entre sistemas autônomos e engenheiros humanos? Que salvaguardas técnicas, evidências operacionais e mecanismos de responsabilização seriam necessários para que as organizações pudessem conceder com confiança mais autoridade à IA sobre infraestruturas de produção críticas para suas operações?

Espero que a IA assuma uma parcela maior do trabalho de reunir as informações sobre um incidente. Os engenheiros poderiam começar com uma linha do tempo útil, os componentes afetados, explicações possíveis e evidências faltantes, em vez de gastar tanto tempo reunindo esse material manualmente.

Isso daria às pessoas mais tempo para tomar decisões que exigem compreender as obrigações do sistema e as consequências de alterá-lo.

Eu ampliaria gradualmente a autoridade para executar ações. Primeiro, um agente poderia operar em modo sombra, gerando recomendações sem colocá-las em prática. As equipes poderiam comparar essas recomendações com os resultados analisados e testar como o agente se comporta quando as informações estão ausentes, são contraditórias ou estão desatualizadas.

A avaliação deve incluir intervenções incorretas, problemas não detectados, escalonamentos desnecessários e a recuperação de erros cometidos pelo próprio agente. Uma recomendação rápida não tem valor se levar a equipe de resposta na direção errada.

A concessão de mais autoridade também deve continuar condicionada. Uma atualização do modelo ou uma mudança importante no sistema pode invalidar testes anteriores. As equipes precisam ter como reduzir ou retirar as permissões do agente quando seu comportamento deixar de atender ao padrão exigido.

A responsabilidade humana não desaparece à medida que a automação avança. Alguém precisa se responsabilizar pelas regras operacionais, pelas evidências exigidas para uma alteração e pelo processo de investigação de falhas.

Vejo os engenheiros dedicando menos tempo à coleta de informações e mais à definição, aos testes e à manutenção das condições que justificam ações automatizadas.

Obrigado pela excelente entrevista. Os leitores que desejarem acompanhar o trabalho dele sobre a confiabilidade de transações distribuídas e a recuperação responsável assistida por IA podem entrar em contato com Sapan Pandya.