Cada empresa com quem conversei nos últimos meses tem a mesma história: agentes de IA estão sendo implantados mais rápido do que as equipes de risco e conformidade conseguem revisar. Aquisição acontece em semanas, análise jurídica leva trimestres, e o intervalo entre essas duas etapas é onde reside a verdadeira exposição.
O seguro tradicional de Erros & Omissões (E&O) nunca foi projetado para essa velocidade. Ele assume um mundo em que os riscos mudam lentamente o suficiente para que uma forma anual e uma ligação telefônica com um corretor sejam suficientes para avaliá-los. Essa suposição desmorona completamente com sistemas autônomos. Um agente pode tomar milhares de decisões por hora, e um modo de falha sutil (o que as pessoas nesse espaço chamam de 'risco silencioso' da IA) pode durar semanas antes que um humano perceba algo errado. Quando uma reclamação é apresentada sob o modelo antigo, o dano já se acumulou, e a seguradora está reconstruindo o que aconteceu a partir de logs e depoimentos em vez de dados em tempo real.
Eu queria me concentrar em uma questão mais estreita e concreta: como seria o seguro se fosse impulsionado por sinais operacionais em tempo real, em vez de papelada estática? Não como um experimento teórico, mas como algo que eu poderia realmente construir e clicar. Essa pergunta se transformou no Recourse.ai, um protótipo para Android criado com o ecossistema da Lloyd's Lab em mente. Ele conecta a telemetria operacional de IA com fluxos de trabalho de seguro paramétrico, convertendo o comportamento real do agente em pagamentos instantâneos e verificáveis sempre que uma barreira de segurança pré-acordada é ultrapassada.
Este post caminha através do que a aplicação faz, por que fiz as escolhas arquiteturais que fiz, onde intencionalmente cortei cantos como protótipo e o que mudaria antes que alguém colocasse dinheiro real nisso.
O que 'paramétrico' realmente significa aqui
O seguro paramétrico não é uma ideia nova. É usado intensamente em áreas como seguros agrícolas e títulos de catástrofe, onde um pagamento é acionado automaticamente assim que uma condição mensurável é atingida (chuva abaixo de X milímetros, velocidade do vento acima de Y nós), ao invés de exigir uma investigação longa de reclamações para estabelecer responsabilidade e danos.
O Recourse aplica essa mesma lógica às operações de IA. Em vez de chuva ou velocidade do vento, a condição acionadora é algo como 'taxa de erro do agente excede um limite definido por um período definido' ou 'um agente toma uma ação fora dos limites aprovados'. Uma vez que essa condição é atingida e verificada contra as regras da política, o processo de pagamento começa automaticamente. Nenhum ajustador precisa reconstruir o que aconteceu semanas depois. Os dados de telemetria que acionaram o pagamento são a evidência.
Isto importa porque muda a estrutura de incentivos dos dois lados. As seguradoras podem avaliar riscos com base em sinais ao vivo, em vez de suposições, e as organizações que estão sendo seguradas têm um incentivo direto para investir em melhores barreiras, porque melhores barreiras literalmente reduzem suas prêmios e sua exposição a reclamações lentas.
O que o Recourse realmente faz
No seu núcleo, a aplicação transforma riscos operacionais de IA em algo mensurável e segurável. Isso é feito através de três capacidades conectadas:
Quantificando risco. Cada agente de IA monitorado recebe uma 'Pontuação da Maturidade do Guardrail', calculada a partir de seu comportamento ao vivo em vez de um checklist auto-relatado preenchido uma vez e esquecido. A pontuação reflete coisas como o quão frequentemente um agente opera dentro dos limites definidos, como ele responde a entradas anômalas e com que frequência é necessária intervenção humana.
Automatizando pagamentos. Quando uma barreira definida é ultrapassada (digamos, a taxa de erro do agente cruza um limite acordado em contrato ou um interruptor de desligamento é ativado), o motor de regras paramétrico verifica a condição contra a política e inicia um pagamento. No protótipo, isso é modelado para ser concluído em menos de 48 horas, uma contraste dramático com os 90 ou mais dias típicos das reclamações E&O tradicionais.
Medindo desempenho. Para líderes financeiros, a aplicação apresenta métricas de ROI e eficiência em tempo real, mostrando como o custo da automação se compara com benchmarks tradicionais e quanto foi recuperado através da própria camada de seguro.
Desenho em torno de personas reais
Em vez de construir um painel genérico e esperar que fosse útil para todos, baseei todo o aplicativo em quatro personas que realmente interagiriam com um produto como esse:
| Persona | Objetivo principal | Característica-chave usada |
|---|---|---|
| CFO / COO | ROI e estabilidade financeira | Métrica de grade executiva (recuperação de fundos, ganhos de eficiência) |
| Diretor de IA | Confiança operacional | Telemetria do agente e interruptores de segurança automáticos |
| Counsel Geral | Governança e auditoria | Auditorias específicas por região (AI Act da UE, DIFC) |
| Broker | Distribuição de capacidade | Monitoramento de capacidade e gerenciamento de políticas paramétricas |
Toda tela no aplicativo retorna a uma dessas pessoas em seu trabalho real. O fluxo de login é orientado por persona, então um CFO que faz o login vê números de recuperação financeira na frente e centro, enquanto um Diretor de IA ao fazer login cai em telemetria do nível do agente. A visão profunda da incidente está escrita para Counsel Geral, com exposição financeira estimada e contexto legal por jurisdição apresentados claramente o suficiente para serem inseridos em uma minuta de conselho. E a tela dos gatilhos das políticas existe principalmente para brokers, mostrando a lógica do motor de regras de maneira transparente em vez de um caixa preta.
Esta abordagem centrada na persona moldou muitas pequenas decisões que poderiam parecer arbitrárias, como por que a tela de entrada executiva é construída para demonstrações instantâneas no conselho diretivo ao invés de uma típica experiência de onboarding do consumidor. O aplicativo não está tentando ser aderente ou formar hábitos. Está tentando ser legível para um tomador específico de decisão em menos de trinta segundos.
Decisões arquiteturais
Eu optei por uma arquitetura MVVM (Model-View-ViewModel) desacoplada no Android. A principal razão foi a separação de preocupações: eu queria que a camada UI permanecesse simples e testável, enquanto toda a lógica de pagamentos e regras comerciais viviam em algum lugar onde pudesse ser raciocinado independentemente de qualquer tela específica.
No prático, isso significa que Activities e seus Adapters lidam com renderização e entrada do usuário, ViewModels mantêm o estado UI como StateFlow, e Repositories têm a responsabilidade de buscar e moldar dados, sejam esses dados provenientes de um banco de dados em tempo real ou uma fonte de fallback. A lógica comercial, incluindo o próprio motor de pagamentos, fica atrás da camada Repository para que não fique entrelaçado com qualquer visual específico.
A camada de dados resiliente
O problema de design mais interessante foi a camada de dados. As demonstrações ao vivo são implacáveis. Uma conexão de banco de dados perdida durante uma apresentação, diante de um auditório cheio de subscritores ou CFOs, mata a credibilidade instantaneamente, independentemente da qualidade real do produto. Então, em vez de assumir que uma conexão com o banco de dados sempre estaria disponível, construí a camada Repository para suportar dois caminhos:
- Uma conexão ao vivo JDBC com MySQL 8.0, dando comportamento de consulta realista através de um esquema de seguro de nove tabelas abrangendo agentes, políticas, incidentes e limites.
- Um módulo fallback "Local Mode" que substitui transparentemente dados mocks de alta fidelidade se o banco de dados não estiver acessível, para que o aplicativo nunca mostre uma tela em branco ou um diálogo de erro diante do público.
A lógica fallback vive em uma classe personalizada DatabaseHelper. Criticamente, os ViewModels acima dele não precisam saber ou se importar com qual caminho realmente serviu os dados. Eles apenas recebem um objeto de domínio e atualizam o estado conforme necessário. Isso manteve a lógica de resiliência contida em um lugar só, ao invés de espalhada como blocos try/catch defensivos por todas as telas.
Aqui está o ciclo de vida da solicitação quando um usuário abre uma incidente, que ilustra como o fallback se encaixa no fluxo normal em vez de ser um caso especial acoplado depois:
Usuário seleciona um incidente
-> View solicita detalhes (incidentId) do ViewModel
-> ViewModel pede ao Repository por telemetria e thresholds
-> Repository consulta MySQL (JOIN entre tabelas de agentes/políticas)
-> se conectado: retorna o ResultSet
-> se não conectado: recorre a dados estratégicos simulados
-> Repository retorna um único objeto do domínio, independentemente da situação
-> ViewModel atualiza o estado da UI
-> View renderiza o relatório de risco e status da reclamação
Kotlin Coroutines e StateFlow lidam com a infraestrutura assíncrona de ponta a ponta. Essa combinação manteve a camada UI livre de callbacks aninhados e tornou os estados de carregamento, sucesso e erro fáceis de representar e testar, já que cada estado é apenas um valor emitido pelo ViewModel em vez de uma cadeia de callbacks de ouvintes.
Por que o "modo local" não é apenas um atalho para demonstrações
Ficaria fácil desconsiderar a fallback de dados simulados como uma maneira rápida de impressionar investidores, e honestamente, parte do propósito disso é exatamente isso. Mas também reflete algo real sobre o modo como esses sistemas precisam funcionar em produção. Uma ferramenta de fluxo de trabalho de seguro que fica inativa no momento em que a conexão com o banco de dados falha não será confiável para lógica de pagamento sensível ao tempo. Construir o padrão de resiliência desde o primeiro dia, mesmo em um protótipo, me forçou a pensar sobre modos de falha cedo em vez de tratá-los como um detalhe posterior quando algo quebra na frente de um usuário real.
A pilha tecnológica e por que cada peça foi escolhida
-
Kotlin como a linguagem principal, utilizando extensões Jetpack KTX (coisas como
isVisible) para manter o código conciso e idiomático em vez de lutar contra a verbosidade do Java. - Material 3 para a camada de interface do usuário, estilizada com uma paleta azul-marinho e teal. O objetivo era fazer o aplicativo parecer um software empresarial sério de finanças em vez de um aplicativo móvel genérico para consumidores, já que o público-alvo é CFOs e Diretores Jurídicos, não usuários do varejo.
- Coroutines e StateFlow para manipulação assíncrona de dados em toda a extensão, o que manteve a gestão de estado consistente em todas as telas ao invés de misturar padrões.
- MySQL 8.0 com JDBC no backend. Escolhi diretamente JDBC em vez de construir uma camada completa de API REST porque a velocidade da prototipagem era mais importante que a correção em produção neste estágio, com a compreensão explícita de que um verdadeiro lançamento precisaria ter uma API autenticada entre as partes.
- Engines de conformidade codificadas manualmente cobrindo o Artigo 14 da Lei Europeia sobre IA, a Regulamentação DIFC 10 e o Sandbox Plus do MAS. Esses não são textos placeholders. O rastreamento de auditoria na visualização detalhada do incidente reflete o texto regulatório real para cada jurisdição, então a história de conformidade se sustenta sob escrutínio de alguém que realmente conhece esses quadros.
Fluxo de dados e sequência por trás de uma reivindicação
Para tornar a verificação do gatilho paramétrico concreta, ajuda caminhar através da sequência completa em vez de apenas descrevê-la em prosa. Quando um usuário seleciona um incidente no painel, o View solicita ao ViewModel detalhes sobre aquele ID específico de incidente. O ViewModel, por sua vez, pede ao Repository para buscar tanto os dados de telemetria quanto as respectivas condições da política. O Repository emite uma consulta SQL que junta entre as tabelas de agentes e políticas no MySQL.
Se a conexão com o banco de dados estiver saudável, a consulta retorna um ResultSet que é mapeado para um objeto do domínio. Se a conexão não estiver disponível, o Repository cai silenciosamente em carregar os dados mock equivalentes, construídos para serem realistas o suficiente que uma pessoa durante uma demonstração não pode notar a diferença. De qualquer maneira, o ViewModel recebe um único objeto do domínio consistente, atualiza o estado da interface de usuário e o View renderiza o relatório de risco junto com o status atual da reivindicação.
O ponto de caminhar por isso em detalhes é que a falha não é uma rota separada de código que diverge do
Resiliência local, com um asterisco. Em um ambiente de produção, o acesso direto JDBC da aplicação cliente seria substituído por uma API REST autenticada. Usar JDBC diretamente no protótipo foi uma escolha deliberada para desempenho e velocidade de desenvolvimento na demonstração, não algo que eu defenderia em uma implementação real lidando com dados reais de segurados.
Licenciamento: por que AGPL-3.0
Eu licenciei o projeto sob a GNU Affero General Public License v3.0, em vez de opções mais permissivas como MIT ou Apache 2.0, e isso não foi uma escolha padrão feita sem pensar.
A argumentação principal para seguros paramétricos neste espaço é que os reivindicações não devem ser um caixa preto. Se essa for a tese real do produto, então o motor de regras decidindo quem recebe e quando deve ser inspecionável por aqueles afetados, não trancado dentro de um serviço hospedado proprietário que ninguém fora da empresa pode auditar. O AGPL especificamente fecha a brecha que o GPL simplesmente deixa aberta: se alguém pegar esse código, modificá-lo e executá-lo como um serviço hospedado sem redistribuir a fonte, o GPL padrão não exigiria que eles compartilhassem essas mudanças. O AGPL faz isso. Isso parecia diretamente alinhado com o que o projeto está tentando provar, em vez de um detalhe legal incidente.
O que eu mudaria antes que isso fosse para perto da produção
Quero ser transparente sobre as partes deste protótipo que são intencionalmente de nível de protótipo, porque uma descrição técnica que fala apenas sobre o que funcionou não é muito útil para quem está construindo algo semelhante.
A conexão direta JDBC da aplicação cliente é a maior delas. É bom para um demo controlado rodando contra um banco de dados que eu controlo, mas seria uma grande responsabilidade em produção. Qualquer versão real disso precisa ter uma API REST ou GraphQL autenticada entre o cliente e o banco de dados, com controle de acesso adequado e limitação de taxa.
O motor de conformidade atual é baseado em regras e codificado por jurisdição. Isso funciona para três regiões em um demo, mas não escala. Uma versão de produção precisaria externalizar essa lógica em um motor de política adequado, algo mais como um sistema de regras como configuração, para que adicionar uma nova jurisdição não signifique enviar um novo build do aplicativo.
Os dados simulados, embora de alta fidelidade, ainda são fabricados. Antes que quaisquer decisões de sub-rogação reais sejam tomadas com base nisso, a pipeline de ingestão de telemetria precisa ser validada contra formatos de log real de agentes em implementações reais, o que varia muito mais do que um conjunto de dados simulado limpo sugere.
E finalmente, a
Onde está indo
O Recourse é explicitamente posicionado como uma aposta de primeiro-mover no espaço de seguros de IA agêntica, e o roadmap reflete essa ambição em etapas. O plano a curto prazo é estabelecer um ponto de apoio no varejo D2C (Direct-to-Consumer), operando dentro de sandbox regulatórios como MAS e ADGM onde a carga de compliance para uma lançamento completo é menor. A partir daí, o caminho se dirige em direção à obtenção de capacidade avaliada com nota A e formalização de um canal de corretagem, já que seguros paramétricos em escala precisam ter uma real capacidade de subscrição por trás deles, não apenas software inteligente. O pivô mais a longo prazo é para distribuição embutida e branqueada em plataformas, então o motor de regras paramétrico poderia eventualmente ficar dentro dos produtos de outras empresas em vez de existir apenas como um aplicativo standalone.
Nenhuma disso é garantida, e muito depende de coisas fora do códigobase, como apetite regulatório e parcerias reais de subscrição. Mas ter uma protótipo funcional que um CFO (Chief Financial Officer), um Head of AI (Chefe de IA) e um General Counsel (Conselheiro Geral) possam clicar e entender imediatamente é um ponto de partida significativamente diferente do que uma apresentação em slides.
Se você quiser olhar para a implementação real, incluindo a camada de dados mock, lógica da engine de compliance e a estrutura MVVM completa, o código-fonte está no GitHub: github.com/alfinohatta/recourse