Blog
ia aplicadamigração digitalpolíticas públicasdados migratóriossistemas de refúgio

Uruguai-Cuba: lições de IA e dados para políticas migratórias

O caso do êxodo cubano no Uruguai mostra como IA e dados bem estruturados podem melhorar políticas migratórias — e quais riscos evitar.

Autor

Alexandre Satochi Yamamoto

13 de setembro de 2026
7 min de leitura
Uruguai-Cuba: lições de IA e dados para políticas migratórias

O fluxo de cubanos para o Uruguai é muito mais do que um fenômeno geopolítico: é um experimento real de transformação social que expõe a fragilidade dos sistemas de informação que deveriam dar suporte a decisões públicas. Quando alguém solicita refúgio, uma cadeia inteira de registros, verificação de identidade, entrevistas e integração local precisa funcionar em sincronia. Poucos países estão preparados para isso com dados confiáveis — e o caso uruguaio, relatado pela BBC, oferece um recorte valioso para quem projeta produtos digitais e sistemas de IA.

Segundo a reportagem, os cubanos hoje são os maiores solicitantes de refúgio e os maiores beneficiários de residência permanente no Uruguai, um país de pouco mais de três milhões de habitantes. O fato é relevante, mas o que mais interessa para engenheiros e arquitetos de software é outra pergunta: que tipo de infraestrutura de dados foi necessária para processar esse fluxo sem colapsar? O texto jornalístico não aprofunda esse ponto, então vou explorá-lo a partir da minha experiência com sistemas distibuídos e políticas públicas orientadas a evidência.

Migração como problema de integração de dados

Projetos de refúgio concentram, em uma única operação, quase todas as dores clássicas da engenharia de dados: fontes heterogêneas, documentos não padronizados, idiomas diferentes, registros inconsistentes e uma necessidade extrema de segurança. Um solicitante cubano pode chegar ao Uruguai com passaporte, certificado de nascimento, comprovações de residência e cartas de familiares — mas esses documentos nem sempre seguem padrões legíveis por sistemas automatizados. Muitos são manuscritos, danificados ou em formatos que um OCR convencional não interpreta bem.

Nesse contexto, a inteligência artificial aparece como ferramenta de apoio, não como solução mágica. Modelos de visão computacional podem extrair dados de documentos antigos; processamento de linguagem natural pode traduzir e resumir formulários; algoritmos de correspondência (entity resolution) podem identificar se duas pessoas mencionadas em documentos diferentes são a mesma. Sem essas camadas, analistas humanos gastariam horas em tarefas mecânicas, atrasando decisões que impactam a vida de alguém.

O que aprendi em projetos semelhantes é que o erro mais comum é começar pela modelagem preditiva antes de garantir a fundação de dados. Você não precisa de um modelo sofisticado para prever o fluxo de chegadas se os registros de entrada são inconsistentes ou duplicados. O Uruguai, por ter uma matriz digital forte, partiu de uma vantagem, mas ainda assim o desafio de interoperabilidade entre órgãos é enorme: polícia, Ministério do Interior, sistemas de saúde e educação precisam falar entre si.

Onde a IA pode atuar de fato

Há pelo menos quatro pontos em que a IA pode gerar ganhos concretos em um sistema de refúgio, todos aplicáveis ao caso uruguaio.

Previsão de fluxos para planejamento de capacidade

Modelos de séries temporais, alimentados com dados econômicos, políticos e de mobilidade, podem ajudar a estimar quantas solicitações chegarão nos próximos meses. Isso permite dimensionar equipes, orçamento e vagas em abrigos antes da crise. O trade-off é conhecido: eventos geopolíticos criam mudanças de regime nos dados históricos. Um pacote de sanções, uma mudança na política de vistos ou uma crise interna em Cuba tornam o passado um péssimo preditor. Por isso, qualquer previsão precisa de monitoramento contínuo e re-treinamento frequente.

Triagem e priorização de casos

Algoritmos de priorização podem classificar solicitações por urgência — como casos de saúde grave, risco de perseguição ou vínculos familiares já estabelecidos no país. Isso reduz o gargalo de entrevistas e direciona atendimento para quem mais precisa. Mas aqui o cuidado deve ser máximo. Modelos treinados em decisões passadas podem aprender vieses históricos, como negar refúgio a quem vem de certas regiões ou grupos demográficos. A solução é usar IA apenas para ranquear e deixar a decisão final com um agente público, em um fluxo humano-no-loop. Além disso, é preciso auditar o modelo periodicamente com dados sintéticos e testes de sensibilidade.

Assistentes de linguagem natural para solicitantes

Muitos cubanos chegam sem dominar o espanhol jurídico, e os formulários oficiais são intimidadores. Um assistente baseado em modelos de linguagem pode explicar direitos, orientar sobre documentos necessários e responder dúvidas em linguagem simples. Isso alivia a carga dos servidores e reduz erros de preenchimento. Do ponto de vista de produto, a implementação não é trivial: é preciso garantir que o assistente não alucine informações sobre prazos legais. A saída técnica é usar geração aumentada por recuperação (RAG), restringindo o modelo a um corpus curado de legislação e procedimentos.

Detecção de inconsistências e fraudes documentais

Análise de grafos e redes de entidades podem identificar padrões suspeitos: um mesmo endereço usado por muitos solicitantes, documentos com números alterados ou familiares que aparecem repetidamente em processos sem relação aparente. Isso não substitui a investigação humana, mas direciona esforços de verificação. O grande risco aqui é o viés de perfilamento: se o sistema mira certos padrões, pode perseguir minorias de forma desproporcional. Recomenda-se que todo alerta seja acompanhado de explicação auditável e que o cidadão tenha direito de contestação.

Privacidade como requisito de arquitetura

Dados de solicitantes de refúgio estão entre os mais sensíveis que existem. Um vazamento pode colocar uma pessoa em risco no país de origem, expondo laços familiares, opiniões políticas ou histórico médico. Isso muda a engenharia desde a concepção: criptografia em repouso e em trânsito é obrigatória, mas insuficiente. É preciso pensar em granularidade de acesso — quem pode ver cada campo, com registros de auditoria — e em políticas de retenção claras. Em conformidade com a LGPD, o consentimento deve ser informado e revogável.

Arquiteturas com dados distribuídos por regiões, ou até em bancos distintos para cada órgão, reduzem a superfície de exposição. Em vez de centralizar tudo em um único data lake, recomendaria uma arquitetura de dados federada, em que cada instituição mantém seus registros e serviços compartilhados consultam somente os campos necessários, via APIs autenticadas. Isso diminui o dano em caso de comprometimento e respeita melhor os princípios de minimização de dados e privacidade desde a concepção.

O que times de engenharia devem levar desse caso

Do ponto de vista de produto, a primeira lição é não tentar construir uma plataforma única e monolítica. O caminho mais sustentável é entregar serviços verticalizados para problemas específicos — como um serviço de extração de documentos, um serviço de previsão de demanda e um assistente de orientação — e permitir que cada órgão adote os que fizerem sentido. Integrações event-driven, com filas e eventos assíncronos, são muito mais tolerantes a picos de carga do que chamadas síncronas entre sistemas.

A segunda lição é investir em qualidade de dados antes de escalar IA. Não existe modelo que corrija uma base com duplicidade de registros, ausência de campos-chave e erros de digitação por muito tempo. Na prática, os primeiros meses de um projeto desse tipo devem ser dedicados à limpeza, à padronização de endereços e nomes, e à definição de identificadores únicos. Sem isso, qualquer painel analítico terá métricas enganosas — o que, no contexto de refúgio, pode significar fila de espera para quem precisa de proteção.

Terceiro ponto: envolva os usuários finais no design. Os agentes públicos que fazem entrevistas e os próprios solicitantes precisam estar no centro do desenvolvimento. Funcionalidades de acessibilidade, interfaces em idiomas adequados e fluxos de contingenciamento para quem não tem familiaridade com tecnologia são tão importantes quanto a precisão do modelo. Em muitos casos, um bom formulário digital, integrado a bases confiáveis, gera mais impacto do que um algoritmo sofisticado.

Riscos de uma abordagem puramente tecnológica

Há um perigo real em tratar a migração como um problema de otimização. Sob o pretexto de eficiência, governos podem usar IA para vigilância excessiva, monitorando refugiados com reconhecimento facial e sensores de localização sem justificativa clara. O mesmo modelo de triagem que acelera casos urgentes pode criar perfis de risco injustos. A resposta não é abandonar a tecnologia, mas regular o seu uso com transparência, auditoria externa e recurso humano obrigatório para qualquer decisão negativa.

Também é preciso considerar a dependência de infraestrutura. O Uruguai tem boa conectividade, mas países menores ou com infraestrutura de nuvem frágil precisam de desenho resiliente, com capacidade de funcionamento offline e processos em papel como redundância. Em qualquer projeto crítico, a pergunta "o que acontece se o sistema cair?" deveria vir antes de "qual é o melhor algoritmo?". Resistência operacional importa mais do que precisão marginal.

Minha leitura como engenheiro

O caso dos cubanos no Uruguai mostra que a tecnologia não resolve por si só os dilemas do refúgio, mas pode criar as condições para que decisões humanas sejam mais rápidas, justas e informadas. A IA aplicada a políticas migratórias é fundamentalmente uma questão de confiança: confiança dos solicitantes nos sistemas que coletam seus dados, confiança dos agentes públicos nas ferramentas que priorizam casos e confiança da sociedade em um processo transparente. Para engenheiros de software, a oportunidade é rara: projetar sistemas que equilibram eficiência, ética e profundidade técnica. Aos times que aceitarem o desafio, sugiro começar pela fundação de dados, manter humanos no controle e desconfiar de qualquer benchmarking que prometa automatizar a proteção.