Resumo

Este artigo propõe uma análise profunda sobre a evolução do desenvolvimento de software, contrastando a era determinística de 2010 com a fluidez do “Vibe Coding” de 2026. Apresento o Analisador de Código (IA Analysis) como uma ferramenta de auditoria multidimensional que utiliza métricas matemáticas de McCabe, Halstead e Shannon para garantir a integridade de sistemas gerados por IA. O trabalho defende que, embora a velocidade da codificação tenha aumentado drasticamente, a responsabilidade ética e técnica do engenheiro — amparada por pilares científicos — permanece como a âncora necessária para a sustentabilidade tecnológica.

1. Introdução: A Grande Transição (2010–2026)

Retroceder ao começo dos anos 2000 é observar um mundo onde o código era esculpido bit a bit. Naquela década, nomes como Donald Knuth ainda ecoavam a ideia de que a programação era uma arte de precisão matemática extrema. O desenvolvedor lidava com uma sintaxe rígida e o ciclo de feedback era lento; errar uma vírgula em C++ ou um ponto-e-vírgula em Java poderia significar minutos perdidos em compilação.

Nessa época, o Stack Overflow estava em sua infância, e a principal ferramenta de “ajuda” era o livro físico. Obras como Structure and Interpretation of Computer Programs (SICP), de Abelson e Sussman, ditavam que o programador deveria ser o mestre absoluto do fluxo de controle. A segurança era uma camada aplicada post-factum, muitas vezes negligenciada até que um ataque ocorresse.

No inicio de 2000, programar era um ato de resistência. Para entender o rigor daquela época, precisamos analisar as tecnologias que sustentavam os gigantes da era pré-IA:

• Facebook (PHP & C++): Mark Zuckerberg e sua equipe tiveram que criar o HipHop (HPHPc) para converter PHP em C++, pois o PHP puro não aguentava o tráfego sem ajuda de IA para otimização.
• Twitter (Ruby on Rails & Scala): Famoso pela “Fail Whale”. O Ruby era lento para o volume de mensagens, forçando a migração para Scala e Java (JVM) para suportar o processamento em tempo real.
• Orkut (ASP.NET/C#): Construído sobre a infraestrutura da Microsoft antes de ser absorvido pelo ecossistema Google. O escalonamento era feito via hardware pesado e balanceamento manual.
• MSN Messenger (C++): Focado em performance de rede e sockets. Cada linha de código de rede era escrita manualmente, garantindo que mensagens chegassem em milissegundos sem abstrações de “vibe”.
• MySpace (ColdFusion & .NET): Um exemplo clássico de “Dívida Técnica”. A dificuldade em migrar o legado de ColdFusion para .NET foi um dos fatores que permitiu a vitória do Facebook.

1.2 O Surgimento do Vibe Coding (2026)

Hoje, em 2026, a realidade é outra. Como definiu Andrej Karpathy (ex-diretor de IA da Tesla), a linguagem de programação mais relevante do momento é o Inglês. Entramos na era do Vibe Coding: um estado de fluxo onde o desenvolvedor “sente” a lógica e a IA generativa (LLMs) traduz essa intenção em milhares de linhas de código instantâneas.

No entanto, essa velocidade gera a Entropia da Inércia. Se não escrevemos cada linha, como garantimos que a IA não introduziu uma vulnerabilidade sutil ou uma dívida técnica impagável? O Analisador de Código foi desenvolvido precisamente para preencher essa lacuna, funcionando como uma consciência algorítmica que valida o fluxo criativo sob a ótica da engenharia clássica.

2. Fundamentação Filosófica: O Código como Práxis Ética

2.1 O Estoicismo na Engenharia

A filosofia estóica, baseada nos ensinamentos de Sêneca e Marco Aurélio, prega que a eficácia reside em focar no que está sob nosso controle. Na engenharia de software, não controlamos a evolução caótica das APIs, mas temos controle absoluto sobre a pureza de nossas abstrações. O analisador é uma ferramenta de disciplina estóica: ele remove o ruído e foca na virtude da clareza, inspirando-se também no conceito de “Pragmatismo” de Andrew Hunt e David Thomas em The Pragmatic Programmer.

2.2 A Realidade Platônica e o Código Limpo

Inspirado na Teoria das Formas de Platão, podemos dizer que o código funcional em produção é apenas uma “sombra” da ideia perfeita. O código limpo, conforme defendido por Robert C. Martin (Uncle Bob) em Clean Code, é a busca pela Forma Ideal. Como diz Uncle Bob:

“A proporção de tempo gasto lendo código versus escrevendo é de mais de 10 para 1. Estamos constantemente lendo código antigo para escrever código novo.”

3. Os Pilares Científicos do Analisador de Código

O motor de análise utiliza métricas matemáticas sólidas para quantificar a “vibe” do código em dados concretos.

3.1 Complexidade Ciclomática (Thomas J. McCabe, 1976)

A complexidade de um programa é medida através do seu grafo de fluxo de controle. A fórmula de McCabe determina o número de caminhos independentes:

$$M = E — N + 2P$$

Onde:

• $E$: Número de arestas (edges).
• $N$: Número de nós (nodes).
• $P$: Componentes conectados.

Um valor de $M > 15$ indica que o código atingiu um nível de ramificação que excede a capacidade de manutenção humana segura, um risco comum em códigos gerados por IA que tentam resolver problemas complexos em blocos únicos.

3.2 Métricas de Halstead (Maurice Halstead, 1977)

Para medir o esforço mental ($E$) e o volume ($V$) do software, o analisador conta operadores e operandos:

• $n_1, n_2$: Número de operadores e operandos distintos.
• $N_1, N_2$: Número total de ocorrências de operadores e operandos.

Calculamos o Volume ($V$) e a Dificuldade ($D$):

$$V = (N_1 + N_2) \times \log_2(n_1 + n_2)$$

$$D = \frac{n_1}{2} \times \frac{N_2}{n_2}$$

O Esforço ($E$) para implementar ou entender o código é dado por:

$$E = V \times D$$

3.3 Entropia de Shannon para Segurança

Para detectar segredos expostos, o módulo de segurança utiliza a Entropia de Shannon ($H$). Chaves criptográficas possuem densidade de informação aleatória superior ao texto comum:

$$H(X) = -\sum_{i=1}^{n} P(x_i) \log_2 P(x_i)$$

Se uma string apresenta alta entropia em contexto de configuração, ela é sinalizada como risco de segurança.

4. Funcionalidades Detalhadas e Regras de Negócio

O Analisador de Código é uma suíte completa de auditoria, baseada nas funcionalidades descritas no repositório:

4.1 🔒 Análise de Segurança

A segurança é tratada como prioridade zero, alinhada ao OWASP Top 10:

• Injeção: Detecção de riscos de SQL Injection e validação de entrada.
• Funções Perigosas: Alerta para o uso de eval() e exec().
• Segredos: Identificação de credenciais hardcoded.
• Criptografia: Detecta o uso inseguro de Math.random(). Edsger W. Dijkstra certa vez disse que "a simplicidade é pré-requisito para a confiabilidade", e isso começa por evitar funções globais perigosas.

4.2 🏗️ Análise de Arquitetura

Focada na sustentabilidade, inspirada em Martin Fowler (Refactoring):

• Acoplamento: Verifica o quão interligados os módulos estão.
• Padrões: Identifica o uso de padrões clássicos do Gang of Four (Factory, Strategy, Observer).
• DRY (Don’t Repeat Yourself): Detecta duplicação de funções similares.

4.3 ✨ Análise de Clean Code

• Dead Code: Remove código comentado e variáveis inúteis.
• Magic Numbers: Sinaliza valores literais sem contexto semântico.
• Deep Nesting: Combate o “aninhamento de flecha” que destrói a legibilidade.

5. Estrutura Técnica do Repositório

O projeto possui uma arquitetura desacoplada, permitindo que o motor de análise seja integrado em pipelines de CI/CD.

5.1 Estrutura de Diretórios

analisador-ia/
├── back-end/
│   ├── analyzers/
│   │   ├── securityAnalyzer.js      # Heurísticas de segurança e Shannon
│   │   ├── architectureAnalyzer.js # Cálculos de McCabe e Halstead
│   │   └── cleanCodeAnalyzer.js     # Regras baseadas em Robert C. Martin
│   ├── server.js                    # Servidor Express API
├── front-end/
│   ├── src/                         # Dashboard reativo em React
└── api/                              # Funções Serverless (Vercel)

5.2 Sistema de Scoring: O Maintainability Index ($MI$)

A pontuação utiliza uma fórmula polinomial para calcular o índice de manutenibilidade:

NívelDeduçãoExemplo de FalhaCritical-10SQL Injection, eval(), CORS permissivoHigh-7Credenciais hardcoded, falta de try-catchMedium-4Complexidade ciclomática $> 15$Low-2Números mágicos, aninhamento profundoInfo-1console.log em produção, uso de var

6. Conclusão: O Papel da UFPR e o Futuro da IA

Como estudante de Especialização em IA Aplicada na UFPR, este projeto representa a convergência entre a inteligência preditiva e a disciplina da engenharia. No futuro, o analisador evoluirá de heurístico para puramente cognitivo, aprendendo com o contexto do negócio.

O Vibe Coding não é o fim da engenharia, é sua evolução para o que chamamos de “Software 2.0”. No entanto, sem ferramentas de controle como este Analisador, corremos o risco de construir sistemas sobre areia movediça. A qualidade é o maior diferencial competitivo de um engenheiro.

Nota: O repositório do projeto está disponível

Referências Bibliográficas

• MARTIN, Robert C. Clean Code. Prentice Hall, 2008.
• FOWLER, Martin. Refactoring. Addison-Wesley, 2018.
• HALSTEAD, Maurice H. Elements of Software Science. Elsevier, 1977.
• HUNT, Andrew; THOMAS, David. The Pragmatic Programmer. Addison-Wesley, 1999.
• MCCABE, Thomas J. A Complexity Measure. IEEE, 1976.

Introdução — por que uma engenheira de software está falando de casarões

Sou engenheira de software e estudante de pós-graduação na Universidade Federal do Paraná (UFPR). O projeto apresentado neste artigo foi desenvolvido como meu Trabalho de Conclusão de Curso (TCC), nascendo no encontro entre formação técnica, pesquisa acadêmica e observação crítica da cidade.

Minha formação me ensinou a pensar em sistemas distribuídos, bancos de dados, arquitetura de software, testes, monitoramento e escalabilidade. Durante muito tempo, associei esses conhecimentos a produtos digitais tradicionais: aplicações corporativas, plataformas web, sistemas de informação.

Foi apenas ao observar a cidade com mais atenção que percebi algo incômodo: a memória urbana também é um sistema — e ele está cheio de falhas.

Casarões históricos existem, mas não estão indexados. Informações existem, mas estão fragmentadas em arquivos físicos, PDFs institucionais, processos administrativos e relatos orais. Há dados, mas não há interface. Há história, mas não há acesso.

Este artigo nasce dessa constatação. Ele é escrito a partir do lugar de estudante, mas também de engenheira de software. Ao longo do texto, discuto o patrimônio histórico a partir de referências institucionais (como o IPHAN), apresento exemplos concretos e explico como o projeto Joi Patrio surge como uma tentativa de tratar a preservação da memória como um problema sociotécnico — e, portanto, também como um problema de engenharia.

Patrimônio histórico: um sistema mal documentado

No Brasil, o Instituto do Patrimônio Histórico e Artístico Nacional (IPHAN) define patrimônio cultural como o conjunto de bens materiais e imateriais que fazem referência à identidade, à ação e à memória dos diferentes grupos formadores da sociedade brasileira. Isso inclui edificações, conjuntos urbanos, paisagens culturais, além de práticas, saberes e expressões.

Do ponto de vista técnico, essa definição revela algo importante: patrimônio é informação estruturada no espaço e no tempo. Um casarão histórico carrega metadados — data de construção, técnica arquitetônica, função original, transformações ao longo dos anos, relação com o território.

O problema é que essa informação raramente está organizada como um sistema. Ela costuma existir em silos: relatórios técnicos, inventários impressos, processos administrativos e arquivos dispersos. Para quem vive a cidade, esse conhecimento simplesmente não aparece.

Em engenharia de software, quando dados existem mas não são acessíveis, dizemos que o sistema falhou em cumprir sua função.

Tombamento: proteção legal sem interface

O tombamento é o principal instrumento jurídico de proteção do patrimônio histórico no Brasil. Ele pode ocorrer em nível federal, estadual ou municipal e estabelece limites para modificações, demolições ou descaracterizações de bens reconhecidos como relevantes.

Do ponto de vista institucional, o tombamento é fundamental. Do ponto de vista do usuário comum — o morador da cidade — , ele é opaco.

Raramente sabemos:

• por que um imóvel foi tombado;
• quais critérios foram usados;
• que histórias estão associadas àquele bem;
• como a população pode participar do processo.

Em termos de engenharia, o tombamento funciona como uma regra de negócio crítica, mas sem camada de apresentação. Existe lógica, mas não existe UX.

Educação patrimonial e o déficit digital

O próprio IPHAN reconhece a educação patrimonial como eixo central da preservação. A ideia é que o patrimônio só se sustenta quando a sociedade o reconhece como valoroso.

No entanto, a maior parte das ações de educação patrimonial ainda opera em modelos analógicos: cartilhas, palestras pontuais, visitas guiadas esporádicas. Enquanto isso, a experiência cotidiana das pessoas acontece em aplicativos, mapas digitais, plataformas colaborativas.

Como estudante de tecnologia, isso levanta uma pergunta direta: por que o patrimônio histórico ainda não foi tratado como um produto digital de interesse público?

Pensar a cidade como arquitetura de software

Na engenharia de software, aprendemos a modelar sistemas complexos usando abstrações: contexto, containers, componentes, fluxos de dados. Ao observar a cidade, percebi que ela também pode ser entendida dessa forma.

• O território funciona como infraestrutura.
• Os edifícios são componentes físicos.
• As histórias são dados.
• As pessoas são usuárias do sistema.

Quando casarões históricos são ignorados ou demolidos sem registro adequado, ocorre uma perda irreversível de dados. Não há backup possível para a memória urbana.

Essa analogia não é apenas retórica. Ela orientou decisões técnicas no desenvolvimento do Joi Patrio.

Joi Patrio: quando patrimônio vira sistema

O Joi Patrio é uma plataforma web dedicada à documentação e valorização do patrimônio histórico de Joinville, com foco em casarões históricos. Do ponto de vista técnico, trata-se de um sistema de informação georreferenciado, com camadas bem definidas.

Arquitetura como escolha política

O projeto foi pensado a partir de uma arquitetura separada em frontend, backend e banco de dados. Essa decisão não é apenas técnica: ela permite escalabilidade, manutenção e eventual expansão para outras cidades.

O frontend, desenvolvido em React, funciona como camada de interação. É ali que a memória ganha interface: mapas interativos, páginas de casarões, buscas e filtros.

O backend, em Node.js, centraliza regras de negócio: validação de dados, controle de acesso, moderação de sugestões da comunidade. Ele garante que a participação coletiva não comprometa a integridade das informações.

O banco de dados MySQL estrutura aquilo que antes estava disperso: dados arquitetônicos, históricos, imagens, comentários e relações espaciais.

Funcionalidades como tradução de conceitos patrimoniais

Cada funcionalidade do Joi Patrio corresponde a um conceito discutido na preservação do patrimônio:

• Cadastro de casarões: equivale ao inventário patrimonial, mas em formato acessível.
• Mapa interativo: transforma o patrimônio em experiência territorial.
• Busca inteligente: rompe com a lógica de arquivos fechados.
• Sugestões da comunidade: incorpora memória social e patrimônio imaterial.
• Favoritos e visitados: reforçam vínculo afetivo e pertencimento.

Essas escolhas não surgem do nada. Elas são resultado de leitura, observação e tentativa de traduzir conceitos teóricos em funcionalidades concretas.

Engenharia de software aplicada à preservação

O Joi Patrio também incorpora práticas clássicas de engenharia de software:

• Testes unitários, usando Jest, para garantir consistência das regras de negócio.
• Monitoramento com New Relic, permitindo observar desempenho e erros em tempo real.
• Infraestrutura com Docker, facilitando replicação e implantação.

Esses elementos são importantes porque tratam o patrimônio histórico com a mesma seriedade que qualquer sistema crítico. Preservar memória exige confiabilidade.

Limites técnicos e éticos

Transformar patrimônio em sistema não significa reduzir sua complexidade. Há limites claros:

• dados históricos podem ser incompletos ou conflitantes;
• relatos da comunidade precisam de curadoria;
• nem toda informação deve ser pública.

Como engenheira em formação, aprendi que sistemas sociotécnicos exigem responsabilidade. Código não é neutro, e plataformas moldam comportamentos.

Considerações finais

Este artigo não é um manual técnico nem um manifesto definitivo. Ele é o registro de um processo de aprendizagem.

Ao desenvolver o Joi Patrio, compreendi que preservar patrimônio histórico não é apenas uma tarefa de historiadores ou arquitetos. É também um desafio de organização da informação, de acesso, de experiência do usuário e de sustentabilidade técnica.

Tratar a memória urbana como um sistema não a empobrece — pelo contrário. Permite que mais pessoas interajam com ela.

Como estudante de engenharia de software, sigo convencida de que código também pode ser ferramenta de preservação cultural.

O código-fonte completo da aplicação, incluindo a modelagem do banco de dados e a API casarões, está disponível no repositório público no GitHub.

O código-fonte completo da aplicação, incluindo a modelagem do banco de dados e a API de validação alimentar, está disponível no repositório público no GitHub.

Introdução — O Abismo Entre Diagnóstico e Vida Cotidiana

A tecnologia, quando aplicada à saúde, tem o potencial de preencher lacunas que o sistema tradicional frequentemente não consegue cobrir com a agilidade necessária. Como engenheira de software e estudante da especialização em Inteligência Artificial Aplicada da Universidade Federal do Paraná (UFPR), meu foco tem sido investigar como dados clínicos podem ser transformados em ferramentas práticas de apoio à decisão — não apenas no diagnóstico, mas também na proteção contínua do paciente.

A doença celíaca é um exemplo emblemático desse desafio. Trata-se de uma condição autoimune crônica severa, muitas vezes reduzida a uma simples restrição alimentar. No Brasil, estima-se que até 80% dos casos permaneçam sem diagnóstico formal, expondo pacientes por anos a inflamação sistêmica persistente, com riscos aumentados de osteoporose, infertilidade, linfomas e outras complicações graves.

Mesmo após o diagnóstico, o risco não desaparece. O celíaco passa a viver em um ambiente de vigilância constante, onde erros de rotulagem, ambiguidades industriais e contaminação cruzada podem comprometer sua saúde. Este projeto nasce exatamente dessa interseção: a união entre Ciência de Dados, Engenharia de Software e IA Aplicada para reduzir riscos clínicos e cotidianos.

1. O Estudo de Caso: Ciência de Dados Aplicada à Saúde

O ponto de partida foi um estudo focado em análise preditiva a partir de exames laboratoriais amplamente utilizados na prática clínica. A pergunta central era direta:

É possível utilizar modelos de aprendizado de máquina para identificar padrões sorológicos associados à doença celíaca com alto grau de confiabilidade, apoiando a triagem médica?

1.1 Conjunto de Dados e Engenharia de Variáveis

O estudo utilizou dados clínicos reais e anonimizados, em conformidade com a LGPD. A análise concentrou-se em três marcadores laboratoriais fundamentais:

• tTG-IgA (Antitransglutaminase Tecidual) — principal exame de triagem
• EMA-IgA (Anti-endomísio) — altamente específico para confirmação
• IgA Total — controle para evitar falsos negativos

Para garantir consistência e rastreabilidade, os dados foram organizados em um banco relacional PostgreSQL. Antes de qualquer modelo de IA, a modelagem do dado foi tratada como etapa crítica de segurança.

CREATE TABLE ingredients (
  id SERIAL PRIMARY KEY,
  name TEXT UNIQUE NOT NULL,
  contains_gluten BOOLEAN NOT NULL
);

Essa estrutura impede inferências implícitas perigosas: um ingrediente nunca “herda” risco automaticamente — ele o declara explicitamente.

1.2 Análise Exploratória de Dados (EDA)

A Análise Exploratória foi conduzida com Python, utilizando Pandas e bibliotecas de visualização. Observou-se uma correlação forte entre níveis elevados de tTG-IgA e diagnósticos positivos, com distribuição assimétrica e presença de outliers.

import matplotlib.pyplot as plt

plt.hist(df["tTG_IgA"], bins=30)
plt.xlabel("tTG-IgA")
plt.ylabel("Frequência")

Esses outliers representam, em muitos casos, possíveis cenários de doença celíaca soronegativa, um desafio clínico real. É exatamente nesse tipo de situação que a IA, quando aplicada com cautela, pode ampliar a capacidade de análise humana ao cruzar múltiplas variáveis simultaneamente.

2. Modelagem: A Escolha Consciente da IA Aplicada

No contexto da saúde, a escolha do modelo é tão importante quanto seu desempenho. Embora redes neurais profundas sejam tecnicamente viáveis, sua aplicação clínica levanta preocupações quanto à explicabilidade e à confiança.

2.1 Regressão Logística e Interpretabilidade

Optou-se pela Regressão Logística como modelo baseline, priorizando transparência e interpretabilidade. Diferentemente de modelos opacos, essa abordagem permite compreender quanto cada marcador contribui para a decisão final.

from sklearn.linear_model import LogisticRegression

model = LogisticRegression()
model.fit(X_train, y_train)

model.coef_

A modelagem utilizou Scikit-learn, incluindo normalização das variáveis, validação cruzada e ajustes para generalização. Em saúde, um modelo compreensível frequentemente é mais valioso do que um modelo apenas mais preciso.

2.2 Métricas e Segurança Clínica

Na detecção de doenças, o recall (sensibilidade) assume papel central. Um falso negativo representa um paciente que continuará consumindo glúten e acumulando danos intestinais silenciosos. O modelo foi, portanto, ajustado para minimizar falsos negativos, priorizando segurança clínica sobre métricas puramente estatísticas.

3. Ética, Responsabilidade e Limites da IA

Desde o início, o projeto foi guiado por princípios claros:

• IA como ferramenta de apoio, nunca substituta do diagnóstico médico
• Anonimização total dos dados clínicos
• Rejeição de inferências automáticas sem base semântica sólida

Esses limites tornam-se ainda mais críticos quando a IA passa a impactar decisões do cotidiano.

4. Da Clínica ao Cotidiano: Segurança Alimentar Baseada em Dados

Durante o desenvolvimento do estudo, tornou-se evidente que o diagnóstico é apenas o primeiro passo. O maior risco para o celíaco ocorre no dia a dia, especialmente diante de rótulos ambíguos.

4.1 O Problema da Rotulagem Alimentar

No mercado brasileiro, é comum encontrar produtos com “NÃO CONTÉM GLÚTEN” em destaque, enquanto a lista de ingredientes menciona derivados como malte ou cevada, ou alertas de contaminação cruzada. Essa contradição transfere ao consumidor uma responsabilidade técnica que ele não deveria carregar sozinho.

4.2 Arquitetura da Solução

Como extensão prática do estudo, está em desenvolvimento uma aplicação full stack voltada à segurança alimentar:

• Front-end (React) — interface clara e acessível
• Back-end (Node.js) — lógica de negócio e validações
• PostgreSQL — base relacional auditável
• IA (OCR + NLP) — extração e análise textual

A decisão final nunca é “inferida” pela IA — ela é sempre consultada a partir do banco de dados.

SELECT
  f.name,
  BOOL_OR(i.contains_gluten) AS contains_gluten
FROM foods f
JOIN food_ingredients fi ON fi.food_id = f.id
JOIN ingredients i ON i.id = fi.ingredient_id
GROUP BY f.name;

Essa consulta garante que um alimento só seja considerado seguro se todos os seus ingredientes forem seguros.

4.3 Um Aprendizado Fundamental: Modelagem Importa

Durante o desenvolvimento, surgiram erros clássicos de engenharia aplicada. Um exemplo foi o caso do arroz — naturalmente sem glúten — sendo classificado incorretamente devido a relações mal definidas no banco.

Esse tipo de falha reforçou uma lição essencial:

Antes de qualquer inteligência artificial, é a estrutura dos dados que garante segurança.

Conclusão — Engenharia como Ferramenta de Proteção

Este projeto demonstra como a IA Aplicada pode transcender a teoria acadêmica e se tornar uma ferramenta concreta de proteção à saúde. A Engenharia de Software fornece a estrutura; a Ciência de Dados fornece o entendimento; a ética garante que ambas sejam usadas com responsabilidade.

Em um cenário de subdiagnóstico e insegurança alimentar, democratizar o acesso a ferramentas inteligentes não é apenas inovação — é cuidado.

Hoje, vou compartilhar com vocês uma história muito pessoal: como descobri minha alergia ao Butylated Hydroxytoluene (BHT) e como essa experiência me levou a criar uma ferramenta que pode transformar a vida de muitas pessoas que passam pelo mesmo que eu passei.

O início: quando tudo começou a dar errado

Minha história com dermatite atópica começou cedo, mas foi só na vida adulta que os sintomas se intensificaram de forma realmente preocupante. As crises de pele, que já eram incômodas, se tornaram frequentes e cada vez mais intensas. Você provavelmente já ouviu falar de dermatite atópica, mas quando você vive na pele, literalmente, você entende o que significa viver com coceiras que não passam, vermelhidão que te impede de usar certas roupas, e a sensação constante de desconforto que te acompanha o dia inteiro — e principalmente à noite.

Mas o que começou apenas como um problema de pele, aos poucos foi evoluindo para algo muito maior. Comecei a emagrecer sem explicação, de forma involuntária e preocupante. Minha flora intestinal estava completamente desregulada. Sintomas gastrointestinais que eu nunca havia tido antes começaram a fazer parte do meu dia a dia: dores abdominais, inchaço, mal-estar constante. Situações que antes eram simples, como comer uma refeição fora de casa, se tornaram fontes de ansiedade.

As noites mal dormidas e a frustração de não saber

As noites se tornaram meu maior pesadelo. Não eram apenas noites mal dormidas — eram noites não dormidas. A coceira na pele me mantinha acordada, mas era mais do que isso: a frustração de não saber o que estava acontecendo comigo era igualmente incapacitante. Você sabe aquela sensação de que algo está errado, mas você não consegue identificar o quê? Era isso, todos os dias.

Eu não conseguia entender por que meu corpo estava reagindo daquela forma. Comia alimentos saudáveis, tentava manter uma rotina equilibrada, mas nada parecia ajudar. A cada crise, a sensação de impotência crescia. Eu me sentia perdida, como se meu próprio corpo estivesse contra mim, e eu não conseguia fazer nada para ajudá-lo.

A busca por respostas: consultas médicas e muitos testes

A jornada até o diagnóstico não foi simples. Foram várias idas ao médico, consultas com dermatologistas, gastroenterologistas, alergologistas. Cada especialista tinha uma teoria, cada consulta trazia esperança, mas também mais testes para fazer.

“Pode ser alergia alimentar”, dizia um. “Pode ser estresse”, sugeria outro. “Pode ser hormonal”, arriscava um terceiro. Todos pareciam fazer sentido de alguma forma, mas nenhum diagnóstico fechava completamente os sintomas que eu estava sentindo.

Os testes de alergia foram longos e exaustivos. Testes cutâneos, exames de sangue, diários alimentares, eliminações progressivas de alimentos. Eu anotava tudo: cada alimento que comia, cada sintoma que sentia, cada produto que usava. Minha vida se tornou um experimento constante tentando descobrir o que estava me fazendo mal.

O momento da descoberta

Foi apenas após vários meses — na verdade, foram quase dois anos desde que os sintomas realmente se intensificaram — que finalmente descobri: eu tinha uma alergia ao BHT, o Butylated Hydroxytoluene.

O BHT é um antioxidante sintético amplamente usado em alimentos, cosméticos, produtos farmacêuticos e até mesmo em embalagens plásticas. Ele está em quase tudo: desde óleos comestíveis e margarinas até batons, cremes, gomas de mascar, cereais matinais. E o pior: ele raramente aparece com o nome completo nos rótulos.

Quando finalmente descobri a causa, foi um misto de emoções. Por um lado, era um alívio enorme finalmente saber o que estava acontecendo comigo. Mas por outro lado, eu me dei conta de que o verdadeiro desafio estava apenas começando.

O desafio real: como identificar produtos com BHT?

Descobrir que você tem uma alergia específica é uma coisa. Descobrir como evitar essa substância em um mundo onde ela está em praticamente tudo é completamente diferente.

O BHT não se esconde apenas atrás do nome “BHT”. Ele aparece com diversos disfarces:

- BHT (o nome mais comum)

- E320 (código numérico na Europa)

- INS 320 (código internacional)

- Butylated Hydroxytoluene (nome completo em inglês)

- Butilado Hidroxitolueno (tradução em português)

E esses são só os nomes mais comuns. Muitas vezes, ele aparece em listas longas de ingredientes. Às vezes, está em inglês quando você menos espera. Outras vezes, está misturado com outros códigos numéricos, fazendo com que “320” passe despercebido em meio a outros números.

Minhas idas ao supermercado:

Minhas idas ao supermercado se transformaram em uma verdadeira batalha. O que antes era uma tarefa rápida e até agradável, se tornou um exercício de paciência e frustração. Eu passava horas lendo rótulo por rótulo, às vezes com uma lupa na mão, tentando encontrar qualquer menção a BHT ou seus códigos.

Imagine a cena: eu no corredor de produtos, de pé, lendo cada ingrediente minuciosamente. Pessoas passando ao meu lado, talvez estranhando. Eu tentando decifrar letras miúdas, códigos numéricos, nomes em inglês. Às vezes, os rótulos estavam em lugares difíceis de ver. Outras vezes, as embalagens estavam danificadas e eu não conseguia ler completamente.

E pior: muitas vezes, depois de todo esse esforço, eu acabava desistindo de comprar o produto porque não conseguia ter certeza absoluta se era seguro ou não. A dúvida era pior do que a certeza. Preferia não comprar do que arriscar passar mal depois.

A vida social que se transformou

Não era só no supermercado. Restaurantes se tornaram um desafio. Como perguntar se o óleo usado na comida tem BHT? Como explicar para um garçom que você precisa saber todos os ingredientes de cada prato? Muitas vezes, eu simplesmente evitava comer fora, o que afetou minha vida social.

Eventos, festas, encontros com amigos — todos se tornaram situações que eu precisava planejar com antecedência. “O que vou comer lá?” era uma pergunta que rondava minha cabeça antes de qualquer compromisso social.

Porque não criar uma solução

Foi durante uma dessas sessões frustrantes de leitura de rótulos que eu tive o que posso chamar de meu momento “eureka”. Como desenvolvedora, eu tinha conhecimento técnico para criar soluções. Por que não usar isso para resolver um problema que era real e que afetava não apenas a mim, mas provavelmente muitas outras pessoas?

Eu pensei: e se eu pudesse criar uma ferramenta que utilizasse inteligência artificial para analisar rótulos e imagens de embalagens? Uma ferramenta que identificasse automaticamente a presença de BHT, mesmo quando ele aparecesse com nomes diferentes ou em imagens difíceis de ler?

A ideia não surgiu da noite para o dia, mas foi se consolidando cada vez que eu passava por mais uma frustração. Eu sabia que precisava fazer algo. Não apenas para mim, mas para todas as pessoas que, como eu, estavam perdendo tempo e qualidade de vida tentando identificar essa substância nos produtos.

Desenvolvendo o BHT Detector: desafios técnicos e pessoais

Criar o BHT Detector não foi simples. Como engenheira de software, eu sabia programação, mas precisava aprender sobre OCR (Reconhecimento Óptico de Caracteres), processamento de imagens, padrões de expressões regulares. Precisava garantir que a ferramenta fosse confiável, porque a saúde das pessoas dependia disso.

Testei a ferramenta com inúmeros produtos reais. Escaneava rótulos, tirava fotos, comparava resultados manuais com os resultados da ferramenta. Cada produto que eu testava era um produto que eu de fato precisava verificar para meu próprio uso.

E a cada teste bem-sucedido, eu pensava: “Como eu queria que isso existisse quando eu descobri minha alergia.” A ferramenta não era apenas um projeto técnico para mim — era pessoal. Era a solução que eu precisava e que outras pessoas precisavam também.

Os diferentes nomes do BHT: por que isso é importante

Uma das partes mais complexas do desenvolvimento foi garantir que a ferramenta reconhecesse todas as variações possíveis do BHT. Eu mesma tinha passado por situações onde um produto tinha BHT escrito de uma forma que eu não reconheci imediatamente.

A ferramenta hoje reconhece:

- Variações do nome completo (Butylated Hydroxytoluene, Butilado Hidroxitolueno)

- Códigos numéricos (E320, INS 320)

- Abreviações e variações (BHT, bht)

- Referências indiretas (antioxidante 320, conservante 320)

Isso era crucial porque, na prática, os rótulos não seguem um padrão. Cada fabricante pode escrever de uma forma diferente, e ainda assim é a mesma substância perigosa para quem tem alergia.

Como a ferramenta funciona: tecnologia a serviço da saúde

O BHT Detector utiliza duas tecnologias principais para análise:

1. Análise de texto: Permite que você cole diretamente a lista de ingredientes de um produto e a ferramenta identifica instantaneamente se há BHT presente.

2. Análise de imagens com OCR: Você pode tirar uma foto ou fazer upload de uma imagem do rótulo, e a inteligência artificial extrai o texto automaticamente, depois analisa se há BHT.

A segunda opção é especialmente poderosa porque resolve exatamente o problema que eu mais enfrentava: ler rótulos com letras pequenas, embalagens difíceis de fotografar, text in ângulos complicados. A ferramenta consegue processar isso para você.

O impacto na minha vida hoje

Criar o BHT Detector mudou minha vida de várias formas. Primeiro, porque agora eu tenho uma ferramenta confiável para verificar produtos rapidamente. Minhas idas ao supermercado ainda são mais cuidadosas do que seriam sem alergia, mas são infinitamente mais rápidas e menos frustrantes.

Mas mais do que isso, saber que outras pessoas podem se beneficiar da ferramenta dá um sentido especial ao que eu criei. Não foi apenas resolver meu próprio problema — foi criar uma solução que pode ajudar outras pessoas que estão passando pela mesma dificuldade que eu passei.

A mensagem para quem também tem alergia ao BHT

Se você também tem alergia ao BHT, ou conhece alguém que tem, eu entendo perfeitamente o desafio. Entendo a frustração de ler rótulo após rótulo. Entendo a ansiedade de não saber se um produto é seguro. Entendo as noites mal dormidas e o impacto na qualidade de vida.

Mas também quero que você saiba que existe uma solução. O BHT Detector foi criado para facilitar sua vida, assim como eu gostaria que tivesse existido quando descobri minha alergia. Não precisa mais passar horas no supermercado com uma lupa. Não precisa mais desistir de produtos por não ter certeza. A ferramenta está disponível e pode ser acessada de qualquer lugar, a qualquer momento.

Olhando para o futuro

Criar o BHT Detector foi mais do que desenvolver uma aplicação — foi transformar uma experiência difícil em uma solução que pode ajudar outras pessoas. Cada vez que penso nas horas que gastei lendo rótulos, penso também em quantas pessoas estão fazendo a mesma coisa agora, e como a ferramenta pode fazer diferença.

Meu sonho é que, no futuro, pessoas com alergia ao BHT não precisem mais passar pela mesma dificuldade que eu passei. Que descubri a presença dessa substância em produtos seja rápido, simples e acessível. E que a tecnologia que eu criei possa ser parte dessa solução.

Uma jornada pessoal que virou solução pública

Minha história com BHT começou com dor, frustração e noites sem dormir. Mas acabou me levando a criar algo que pode fazer diferença na vida de outras pessoas. Nem sempre as dificuldades da vida nos levam a criar soluções, mas quando isso acontece, é especialmente significativo.

Se você tem alergia ao BHT, espero que o BHT Detector possa facilitar sua vida. E se você conhece alguém que tem, compartilhe a ferramenta. Porque ninguém deveria ter que passar horas lendo rótulos, quando tecnologia pode fazer isso de forma mais rápida e confiável.

A tecnologia existe para resolver problemas reais. E este, definitivamente, é um problema real que precisava de uma solução.

*O BHT Detector ainda está em teste*

E às vezes, esse preço também é jogável.

Por Costanza Pasquotto Assef | Engenheira de Software e Estudante de Especialização em IA Aplicada na UFPR

Introdução

Perder alguém que amamos é uma experiência universal, mas profundamente íntima. O luto nos transforma, nos quebra e, lentamente, nos reconstrói com outras formas, outras cores. Eu, Costanza, conheço esse processo. Já vivi o vazio deixado pela ausência de pessoas que amava profundamente. Busquei refúgio em muitas formas de arte, mas foi nos jogos que encontrei um espelho sensível e interativo para a dor que me atravessava.

Inspirada pelo livro “O Cérebro de Luto: Como a mente nos faz aprender com a dor e a perda”, da neurocientista Mary-Frances O’Connor, decidi explorar como os jogos digitais — muitas vezes vistos como escapismo — são também espaços de imersão emocional e de acolhimento da dor. O livro explica que o luto é um processo de aprendizagem: o cérebro precisa se reconfigurar para entender que aquela pessoa amada não está mais presente. E jogos, por sua natureza, permitem simular, repetir, reconfigurar.

Neste artigo, proponho uma análise profunda de como alguns jogos abordam o luto — seja como tema central, pano de fundo ou metáfora mecânica — e de que maneira eles constroem uma filosofia de perda através de narrativa, jogabilidade e estética.

The Illusionist’s Dream — Metamorfoses de uma ausência

Lançado em 2010 como um jogo em Flash por Matt Dibble, “The Illusionist’s Dream” parece simples à primeira vista: um pequeno jogo de plataforma, com um mágico melancólico como protagonista. Mas por trás de sua estética delicadamente desenhada à mão, esconde-se uma história comovente sobre a perda de um grande amor.

O protagonista, devastado pela morte de sua amada, começa a sonhar. E nesses sonhos, ele se transforma — literalmente. Em cada fase, ele assume a forma de animais para ultrapassar obstáculos. A mecânica não está lá apenas para diversificar o gameplay, mas para representar o próprio luto: a necessidade de se adaptar, de se reinventar diante da ausência.

O jogo não recompensa o jogador com pontuações ou upgrades. Ele oferece silêncio, atmosfera, introspecção. É uma experiência breve, mas poderosa — uma metáfora jogável da dor que transforma.

Sonho de Despedida: Vozes do Além no Ilusionista

“Why are you here?”
“Por que você está aqui?”
→ Uma pergunta direta, que expressa surpresa, talvez angústia. Sugere que a presença da outra pessoa é inesperada ou emocionalmente carregada.

“You of all beings should know: Death is just transformation.”
“Você, dentre todos os seres, deveria saber: a morte é apenas transformação.”
→ Uma afirmação filosófica poderosa. Indica que a morte não é fim, mas transição — um tema comum em obras que tratam de luto com profundidade espiritual.

“You won’t find me, my love. Yet here I linger.”
“Você não vai me encontrar, meu amor. E ainda assim, eu permaneço aqui.”
→ A dor da ausência se mescla com a ideia da presença emocional. Não se pode mais ver ou tocar a pessoa amada, mas ela ainda “permanece” de alguma forma: na memória, na alma, nos gestos.

“I will always be with you. But for you to appreciate my presence… you must let me go.”
“Eu sempre estarei com você. Mas, para que você possa valorizar minha presença… você precisa me deixar ir.”
→ Um dos paradoxos mais bonitos do luto. A presença só se torna suave e viva quando a perda é aceita. Isso ecoa diretamente o conceito do livro O Cérebro de Luto: aceitar é integrar, não apagar.

“Can you feel the loneliness? Poison in your veins. Here, in your fiery heart.”
“Você sente a solidão? Veneno em suas veias. Aqui, em seu coração em chamas.”
→ Luto como dor física e emocional. A solidão é comparada a veneno: algo que consome por dentro, silenciosamente.

“Face your demons, and burn them away.”
“Enfrente seus demônios, e os queime.”
→ Um chamado à coragem. O luto também pode se tornar um terreno fértil para enfrentar traumas antigos, arrependimentos, medos. “Queimar” é aqui uma metáfora para a purificação.

“Death came to me like it comes to us all.”
“A morte veio até mim como vem para todos nós.”
→ Aceitação universal. Ninguém escapa da morte. Humaniza o que é inevitável.

“In death, life goes on… and in life, so must you.”
“Na morte, a vida continua… e na vida, você também deve continuar.”
→ Um lembrete gentil, mas firme: seguir em frente é necessário. A vida após a perda ainda é vida.

“Jump and wake up, my love. Wake up.”
“Salte e acorde, meu amor. Acorde.”
→ Pode representar o momento em que o personagem (ou jogadora) precisa despertar para a realidade — uma libertação simbólica do ciclo de luto.

Onde jogar?

The Illusionist’s Dream 🕹️ Play on CrazyGames

The Last of Us — O amor e a fúria

Poderíamos dizer que toda a saga “The Last of Us” é uma ode à dor da perda. Logo na cena de abertura do primeiro jogo (2013), Joel vê sua filha Sarah morrer em seus braços. É um momento visceral, que nos arranca da cadeira e nos coloca diretamente dentro de uma ferida aberta.

Joel sobrevive, mas nunca mais é o mesmo. Quando conhece Ellie, anos depois, sua armadura emocional é visível. Mas é através da convivência com ela que o elo se reconstrói. No entanto, o que “The Last of Us Part II” nos entrega não é uma história de superação linear, mas uma espiral de perdas.

Ellie, agora crescida, perde Joel — seu pai substituto, seu mundo. O jogo nos força a experimentar a raiva, a vingança, o desespero. Mas também a inevitável ressaca emocional que vem depois da fúria. A depressão. A paralisia. A culpa.

A filosofia aqui é crua: o luto é irracional, doloroso, destrutivo. Mas, como no livro de O’Connor, é também um processo de reconstrução. A mente se reconfigura — e, no caso de Ellie, isso envolve também desapegar-se da violência como mecanismo de sobrevivência.

Onde jogar?

The Last of Us™ Parte I — Jogos de PS5™ | PlayStation (Brasil)

The Last of Us Parte II — Jogos de PS4 | PlayStation (Brasil)

The Last of Us™ Part I no Steam

The Last of Us™ Parte II Remastered no Steam

Life is Strange — O que não pode ser desfeito

“Life is Strange” (2015) é sobre juventude, escolhas e… inevitabilidade. Max, uma adolescente com o poder de voltar no tempo, tenta salvar Chloe, sua melhor amiga. Mas por trás dessa amizade está a sombra constante de Rachel Amber — a garota desaparecida, morta, e cuja ausência ecoa em cada esquina.

Rachel nunca aparece viva. Mas sua presença molda os personagens, principalmente Chloe. O luto aqui é vivo, pulsante, moldado por raiva, nostalgia, idealização e saudade. O jogo nos faz reviver momentos, tentar consertar o passado, e falhar. Porque há coisas que simplesmente não podem ser desfeitas.

No final, a jogadora é forçada a fazer uma escolha impossível: sacrificar Chloe para salvar a cidade ou deixá-la viver e aceitar a destruição. Uma metáfora cruel, mas verdadeira: o luto exige escolhas que nunca parecem justas.

Em Life is Strange: Before the Storm, voltamos um pouco no tempo e acompanhamos Chloe lidando com outra perda: a morte de seu pai, William. A ausência paterna molda seu temperamento, sua rebeldia, sua carência. Ao mesmo tempo, vemos sua ligação profunda com Rachel se formando — e sabemos, como jogadoras, que aquilo que floresce também será arrancado. A morte de Rachel não é apenas mais uma tragédia: é o ponto final de um raro momento de felicidade que Chloe encontrou depois da perda do pai.

Onde jogar?

Life is Strange - Episode 1 on Steam

Obter o Life Is Strange | Xbox

Red Dead Redemption 2 — A morte como horizonte

Arthur Morgan é um dos personagens mais complexos da história dos jogos. Em “Red Dead Redemption 2”, acompanhamos sua lenta decadência física e emocional. Diagnosticado com tuberculose, ele passa a encarar a morte não como inimiga, mas como uma companheira silenciosa.

O jogo não nos dá uma missão de cura. Nos dá tempo. Tempo para refletir. Para ajudar os outros. Para escrever cartas. Para se arrepender. Arthur lida com perdas sucessivas: de amigos, da honra, da juventude, da liberdade. E nós, como jogadores, sentimos cada uma dessas ausências.

Em um dos momentos mais sinceros e marcantes da narrativa, Arthur diz: “Eu estou com medo.” — uma frase curta, mas devastadora. Porque ali está um homem forte, calejado, confessando a fragilidade mais humana de todas diante do fim iminente.

A filosofia aqui é a da aceitação. A morte é inevitável. O que importa é o que fazemos com o tempo que temos. E o luto é, talvez, a forma mais humana de demonstrar que vivemos de verdade.

Onde jogar?

Red Dead Redemption 2 no Steam

Red Dead Redemption 2 — Rockstar Games

Moonlight Lovers e a prisão do luto eterno-Ethan

Em Moonlight Lovers: Ethan, o luto se manifesta de maneira sutil — e talvez mais sombria. Ethan, um vampiro imortal, carrega a dor de perdas passadas que nunca cicatrizaram. A imortalidade aqui não é liberdade, mas condenação: à saudade, à culpa, à impossibilidade de seguir em frente.

Ethan perdeu não apenas pessoas queridas ao longo dos séculos, mas também partes de si mesmo. Seu coração, antes vibrante, foi se tornando uma prisão emocional. Ele tem medo de se apegar, pois sabe o preço que pagou no passado. Ao interagir com ele, sentimos o peso dessas ausências. Há um tom constante de melancolia em suas palavras, como se ele estivesse sempre à beira de um suspiro.

Mas é com a chegada de Eloise — a personagem principal, que o jogador controla — que esse ciclo começa a se transformar. Eloise não tenta apagar o passado de Ethan. Ela o escuta, o compreende, o desafia a viver algo novo. Em pequenos gestos, diálogos, decisões, ela o ajuda a desenterrar sentimentos soterrados pela eternidade.

Com Eloise, Ethan aprende que o luto pode coexistir com o amor. Que lembrar não é o mesmo que se aprisionar. Que a dor pode dar lugar ao afeto, sem deixar de ser parte dele. O romance entre os dois não é apenas uma história de paixão, mas um lento e poético processo de cura.

Ethan representa o luto congelado no tempo. Eloise, a possibilidade de descongelar — de transformar memórias em movimento, perda em presença viva.

Onde jogar?

Moonlight Lovers | The new vampire and romance online game

Five Nights at Freddy’s — O luto como vingança e assombro

Na franquia Five Nights at Freddy’s, o terror vai muito além de robôs animatrônicos assassinos. Por trás da estética de jumpscares e tensão noturna, há uma narrativa trágica: a morte de várias crianças em circunstâncias brutais, e a forma como suas almas passam a habitar os próprios animatrônicos.

Essas crianças, vítimas de violência, não encontram descanso. Buscam vingança. Buscam justiça. O luto aqui é coletivo, violento, preso entre circuitos e metal. Os jogos propõem uma visão sombria: quando a dor da perda não é acolhida, ela se transforma em fúria eterna.

A procura pelo homem roxo responsável por todas as mortes faz com que as crianças fiquem cegas por vingança.

Em FNAF 4, conhecemos a história da Criança Chorona — um garoto sensível, assombrado por pesadelos e pela zombaria do irmão mais velho. No final, após uma brincadeira cruel que termina com sua morte, vemos o impacto dessa tragédia se espalhar. O irmão, muitas vezes interpretado como o responsável, carrega esse trauma consigo. O luto, nesse caso, vira um ciclo de culpa, repressão e punição.

Em FNAF 3, entitulado “The Happiest Day” ou seja o dia mais feliz, é quando as crianças finalmente conseguem se vingar e assim descansam em paz, uma das cenas mais tristes da franquia, mas que de certa forma é bonito de se ver.

“You’re free now, children. You don’t have to suffer anymore.”

A filosofia do luto em FNAF é a do não-dito. Do trauma que se esconde em corredores escuros. Da dor que retorna noite após noite até ser reconhecida.

Onde jogar?

Five Nights at Freddy’s no Steam

A Neurociência do Luto — Aprendizado, dor e memória

O livro “O Cérebro de Luto” nos mostra que o luto não é apenas tristeza: é uma função cognitiva. A mente precisa aprender que a pessoa amada não voltará. Os circuitos de memória, recompensa e apego precisam ser reprogramados — e isso dói. Literalmente.

Jogos, nesse contexto, são uma mídia perfeita para simular esse processo. Podemos revisitar memórias, repetir escolhas, viver a dor em pequenas doses. E, quem sabe, sair disso com mais empatia. Com mais humanidade.

Conclusão — Um luto que se joga

O luto não é um obstáculo a ser superado. É um território a ser explorado. É um espaço de vulnerabilidade, de reencontro com a memória, de metamorfose interna. Jogos que abordam o luto não querem nos curar — querem nos acompanhar.

Assim como o cérebro precisa de tempo e repetição para processar a perda, os jogos nos permitem simular essas repetições. Refazer passos. Escolher de novo. Sentir, aos poucos, a dor se transformando em lembrança.

O luto é inevitável. Mas nunca solitário. E talvez, entre uma escolha e outra, entre a vida e a morte, entre o amor e a ausência, possamos encontrar algum sentido. Mesmo que seja apenas o de continuar.

Por Costanza Pasquotto Assef

Por Costanza Pasquotto Assef | Engenheira de Software e Estudante de Especialização em IA Aplicada na UFPR

1. Introdução

A inteligência artificial (IA) tem transformado diversos setores, e no combate a incêndios e resgates emergenciais sua aplicação vem se mostrando promissora. Desde a detecção precoce de focos até o suporte à decisão em campo, a IA pode salvar vidas e preservar bens.

2. Contexto: Desafios enfrentados pelos bombeiros

Os bombeiros lidam com cenários dinâmicos e de alta complexidade — como incêndios florestais, prédios urbanos e resgates em ambientes hostis. A tomada de decisão rápida e eficaz é crucial, mas muitas vezes limitada pela falta de informações em tempo real ou pela dispersão de dados.

3. Aplicações da IA no combate a incêndios

3.1 Prevenção e detecção precoce

• Câmeras equipadas com IA identificam fumaça e focos de incêndio com precisão, enviando alertas em tempo real. Um projeto no Distrito Federal utiliza câmeras na Torre de TV Digital para monitorar o cerrado num raio de até 25 km, acionando o Corpo de Bombeiros rapidamente SBT News+1Correio Braziliense+1.
• Nos Estados Unidos, redes como ALERTCalifornia usam câmeras e satélites com IA para detectar incêndios antes mesmo de serem reportados por humanos — reduzindo tempo de resposta e danos potenciais

3.2 Previsão e análise de risco

• Sistemas como WIFIRE e iniciativas da Technosylva processam dados atmosféricos, vegetação e clima para prever trajetórias de incêndios com alta precisão e rapidez, ajudando no planejamento estratégico The Guardian+1TIME+1.
• O European Centre for Medium‑Range Weather Forecasts desenvolve previsões globais de incêndios com resolução diária e até 10 dias de antecedência news.microsoft.com+3cbm.sc.gov.br+3noticias.unb.br+3.

3.3 Apoio operacional e situacional

• Projetos acadêmicos utilizam deep learning e realidade aumentada para aumentar a consciência situacional dos bombeiros. Sistemas baseados em Mask‑RCNN, detecção de objetos, tracking e navegação assistida ajudam a localizar saídas seguras em condições visuais adversas arxiv.org.
• Algoritmos em tempo real analisam imagens obtidas por drones ou câmeras instaladas no cenário de fogo para apoiar o comandante da operação e garantir rastreamento da equipe researchgate.netapps.usfa.fema.gov.

3.4 Drones e veículos autônomos

• No Brasil, o Corpo de Bombeiros do Amazonas desenvolveu drones especializados para combate e monitoramento de incêndios florestais cbm.am.gov.brparana.pr.gov.br.
• Nos EUA, helicópteros autônomos retrofitados com IA — parte de um projeto da DARPA/Texas A&M — realizam lançamentos de água, patrulhamento aéreo e apoio logístico sem piloto humano chron.com.

3.5 Engenharia de segurança e simulação

• Ferramentas como o IFETool aplicam IA para simular a visibilidade de fumaça, temperatura e gases em ambientes fechados, acelerando os projetos de segurança contra incêndio com altíssima precisão (~97 %) sciencedirect.com+1researchgate.net+1.
• Gêmeos digitais (“Digital Twins”) combinam sensores IoT, modelos BIM e IA para monitorar edifícios em tempo real e antecipar riscos researchgate.net.

4. Benefícios e considerações

• Redução do tempo de resposta: detecções automatizadas e previsões antecipadas aceleram o despacho de equipes The Guardianinternationalfireandsafetyjournal.com.
• Melhor alocação de recursos: com previsões e detecções precisas, equipamentos e efetivos podem ser distribuídos de forma mais eficiente.
• Maior segurança operacional: vigilância via drones e câmeras com IA melhora a visão do comandante sobre perigos invisíveis (flashover, fumaça) nist.gov+1nist.gov+1.
• Capacitação mais eficaz: simulações realistas com IA favorecem o treinamento de cenários críticos.
• Desafios éticos e legais: privacidade, viés em dados e dependência excessiva de decisões automatizadas são preocupações importantes internationalfireandsafetyjournal.comjensenhughes.com.

5. Casos no Brasil e na região

• Santa Catarina (CBMSC) já emprega IA no atendimento ao 193 para registro e despacho de ocorrências via Centros de Operações cbm.sc.gov.br.
• Distrito Federal (DF) usa câmera‑IA no cerrado, com alertas que levam a ações preventivas rápidas e redução significativa de queimadas Correio Braziliensenoticias.unb.brSBT News.
• Amazônia (CBMAM) testa drones brasileiros especificamente adaptados para detectar áreas de risco e apoiar operações de combate cbm.am.gov.br.

6. Perspectivas futuras e recomendações

• Expansão do uso de satélites de monitoramento global, drones e sensores conectados em rede washingtonpost.com.
• Criação de protocolos e regulações para uso responsável da IA em emergências públicas (PL 1807/2025 discute alocação de recursos para IA em segurança pública) www12.senado.leg.br.
• Integração entre corpo de bombeiros, universidades, empresas de tecnologia e governos para desenvolver soluções à prova de falhas e replicáveis.

7. Conclusão

A inteligência artificial já está tornando o combate a incêndios e operações de resgate mais inteligentes, seguras e eficientes. Embora existam desafios técnicos, éticos e de implementação, os exemplos nacionais e internacionais mostram que a IA pode ser uma aliada decisiva na proteção de vidas e do ambiente. O avanço da infraestrutura tecnológica e das regulamentações será crucial para ampliar esse impacto.

“Aviões não caem por um único motivo — eles caem por cadeias de decisões falhas.”
 — Cultura da Segurança na Aviação

No imaginário popular, acidentes aéreos são causados por falha humana ou condições meteorológicas severas. No entanto, dois dos acidentes mais trágicos da aviação moderna desafiaram essa lógica: o caso dos voos Lion Air 610 e Ethiopian Airlines 302, ambos envolvendo o Boeing 737 MAX 8, teve como principal causa uma falha de software.

Entre 2018 e 2019, 346 pessoas morreram em dois acidentes quase idênticos — ambos causados por um sistema automatizado chamado MCAS (Maneuvering Characteristics Augmentation System). Essa falha abalou a confiança em uma das maiores fabricantes aeronáuticas do mundo e acendeu alertas globais sobre o uso de software em sistemas críticos.

O Boeing 737 MAX: Uma Corrida Contra o Tempo

Para entender a tragédia, é preciso voltar ao início da década de 2010. A rival Airbus havia lançado o A320neo, uma versão mais eficiente da sua aeronave de médio porte, com novos motores que economizavam combustível. A resposta da Boeing veio em 2011: o 737 MAX, uma atualização de sua aeronave mais vendida, prometia os mesmos ganhos de eficiência com novos motores.

Mas havia um problema técnico: os motores LEAP-1B usados no MAX eram maiores e mais avançados, e precisaram ser reposicionados mais à frente e acima da asa para caberem no design tradicional do 737. Isso mudou o centro de gravidade e alterou a aerodinâmica da aeronave, especialmente durante ângulos de subida acentuados.

Para “corrigir” esse comportamento e evitar que o avião se comportasse de forma imprevisível em certas situações, a Boeing criou o MCAS — um sistema automatizado que, ao detectar uma inclinação do nariz muito elevada (angle of attack, ou AOA), forçava automaticamente o nariz do avião para baixo.

MCAS: O Software que Deveria Ajudar, Mas Matou

O MCAS foi uma solução de software criada para manter o “comportamento esperado” do avião sem precisar modificar o treinamento dos pilotos. A Boeing, para manter a certificação do MAX como uma variante do 737 anterior, buscava evitar um novo processo de homologação pela FAA (Administração Federal de Aviação dos EUA) — o que custaria tempo e dinheiro.

Entretanto, o sistema foi desenvolvido com decisões de engenharia altamente arriscadas:

• O MCAS recebia dados de apenas um único sensor de AOA (ângulo de ataque). Se esse sensor falhasse ou entregasse dados incorretos, o sistema não tinha verificação cruzada.
• O sistema não informava claramente os pilotos quando entrava em ação.
• Em caso de erro, o MCAS podia repetidamente empurrar o nariz do avião para baixo, mesmo com tentativas dos pilotos de recuperar o controle.
• O manual de operação da aeronave sequer mencionava o MCAS, e os pilotos não foram treinados para reconhecer e lidar com sua ativação.

Decisões de Engenharia que Custaram Vidas

1. Dependência de um Único Sensor (Anti-pattern: Single Point of Failure)

O MCAS foi projetado para confiar em apenas um dos sensores de ângulo de ataque (AOA) disponíveis. Em engenharia de sistemas críticos, isso é imperdoável. O sensor era analógico, externo e sujeito a falhas físicas (impacto, sujeira, calor).

💡 Como desenvolvedores, isso equivale a confiar cegamente em um input externo sem validação ou fallback.

Lição: Dados de entrada devem ser verificados, redundantes e validados com lógica de consenso. Em sistemas críticos, NUNCA confie em um só ponto de entrada.

2. Ausência de Comunicação com o Usuário Final (UI/UX Invisível)

Os pilotos não sabiam que o MCAS existia, e tampouco havia alertas visuais ou sonoros claros quando o sistema era ativado. Ou seja, uma automação “fantasma”, operando em silêncio.

💡 Na prática: um sistema automatizado tomou controle do avião sem dizer nada ao usuário — isso é equivalente a um app que deleta dados sem feedback ou botão de desfazer.

Lição: Mesmo em sistemas automáticos, a interface com o operador humano precisa ser transparente e explicável. Feedback é parte da segurança.

3. Cultura de Ocultação e Débito Técnico Intencional

Para evitar que as companhias aéreas tivessem que treinar novamente os pilotos (o que custaria milhões), a Boeing escondeu o MCAS dos manuais. Isso é o equivalente a um código em produção com comportamento crítico oculto e não documentado — o código morto-vivo que pode ser ativado sob certas condições obscuras.

💡 Isso não é apenas um problema de código — é um problema de cultura corporativa.

Lição: Transparência técnica não é opcional. Se você precisa esconder uma feature para que ela “não atrapalhe” o usuário, talvez ela não devesse existir.

4. Automação Irreversível e Não Observável (Fail-Unsafe Behavior)

O MCAS podia se ativar repetidamente, a cada novo ciclo de leitura do sensor. Mesmo quando os pilotos tentavam levantar o nariz, o sistema tomava o controle de volta — sem nenhuma validação externa.

💡 É o equivalente a um sistema de autosave que salva um estado corrompido toda vez, sobrescrevendo a versão anterior sem aviso.

Lição: Em automações críticas, é preciso implementar limites de ativação, rollback, timeouts e observabilidade. Isso é arquitetura segura — e humana.

5. Falta de Testes de Cenários Reais (Happy Path-Driven Development)

O MCAS foi testado em simuladores sob condições ideais. Mas falhas reais, como sensores danificados ou reações de pilotos, não foram bem simuladas. O famoso “happy path” foi seguido à risca — até que a realidade o quebrou.

Lição: Testar apenas os caminhos de sucesso é suicídio em sistemas críticos. Testes de borda, falhas forçadas, testes com usuários sob estresse — tudo isso deve fazer parte do ciclo.

Os Acidentes

Voo Lion Air 610 — Outubro de 2018

• A aeronave havia apresentado problemas com o sensor de AOA em voos anteriores.
• Durante a decolagem, o MCAS foi ativado repetidamente, forçando o nariz do avião para baixo.
• Os pilotos, sem conhecimento do sistema, tentaram contrariar a ação manualmente, mas não conseguiram controlar a aeronave.
• O avião caiu no Mar de Java, matando 189 pessoas.

Voo Ethiopian Airlines 302 — Março de 2019

• Cinco meses depois, em condições muito semelhantes, outra aeronave do mesmo modelo caiu na Etiópia.
• O MCAS novamente foi ativado com base em um único sensor com defeito.
• Os pilotos tentaram seguir os procedimentos emergenciais, mas o sistema já havia forçado o avião para uma descida incontrolável.
• 157 pessoas morreram.

As consequências

Após o segundo acidente, o 737 MAX foi proibido de voar no mundo todo. O modelo só voltou ao serviço quase dois anos depois, com mudanças significativas:

• O MCAS foi redesenhado para usar dois sensores AOA e se desativar após conflito de dados.
• Pilotos passaram a receber treinamento específico sobre o sistema.
• A FAA passou a adotar processos mais rigorosos para validar alterações de software.

As consequências financeiras para a Boeing foram devastadoras:

• Mais de US$ 20 bilhões em perdas, entre multas, indenizações e cancelamentos.
• Imagem pública e confiança abalada.
• O CEO da Boeing foi demitido.
• Diversos engenheiros e executivos foram investigados.

Lições para a engenharia de software crítica

Esse caso não é apenas sobre aviação. Ele traz lições profundas para quem trabalha com engenharia de software em sistemas críticos:

• Redundância não é opcional. Em software que controla máquinas com vidas humanas em jogo, falhas devem ser toleradas e previstas.
• Transparência salva vidas. Esconder funcionalidades para evitar treinamentos é uma violação da ética em engenharia.
• Sistemas devem ser explicáveis. Automação cega, sem feedback para o operador humano, cria riscos graves.
• Testes não podem simular apenas o “ideal”. O MCAS funcionava bem quando o sensor estava correto. Mas não foi testado o bastante para falhas plausíveis.
• A cultura importa. Pressões comerciais jamais podem sobrepor a segurança do usuário final.

Conclusão

O caso do Boeing 737 MAX é um divisor de águas na relação entre tecnologia e segurança. Ele nos lembra que nenhuma linha de código é neutra — e que decisões de software, por menores que pareçam, podem ter impacto em escala global.

Para engenheiros, desenvolvedores e arquitetos de sistemas, esse episódio serve como um lembrete brutal: ética, responsabilidade e engenharia bem-feita não são luxos — são pré-requisitos.

Quando o software cai, vidas podem cair com ele.

Fontes e Leituras Recomendadas

• Relatório final do voo Lion Air 610 (KNKT)
• Relatório preliminar do voo Ethiopian Airlines 302
• Frontline (PBS) — Boeing’s Fatal Flaw (documentário completo)
• IEEE Spectrum — What Really Brought Down the Boeing 737 Max?

Por Costanza Pasquotto Assef | Engenheira de Software e Estudante de Especialização em IA Aplicada na UFPR

Recentemente, assisti a uma palestra inspiradora da Giovana Resende Lima na Codecon, onde ela abordou os desafios técnicos da escalabilidade em sistemas de alto tráfego. Foi a partir daquela apresentação que percebi o quanto esse conceito impacta diretamente a experiência dos jogadores — e essa reflexão foi o ponto de partida para este artigo.

Com o crescimento explosivo do mercado de jogos online, especialmente os multiplayer, a qualidade da experiência do jogador não depende apenas de gráficos bonitos ou de um enredo envolvente. Existe um fator muitas vezes negligenciado fora do meio técnico, mas absolutamente central: a escalabilidade.

Sou estudante de Inteligência Artificial na Universidade Federal do Paraná (UFPR) e, desde que comecei a estudar sistemas distribuídos e arquitetura de servidores, ficou claro para mim que muitos dos problemas enfrentados por jogos online têm origem justamente na ausência de escalabilidade — ou na sua implementação mal planejada.

Em 2025, um caso chamou especialmente a atenção: Animal Jam, um jogo online popular entre crianças e adolescentes, passou a sofrer com quedas frequentes de servidor, travamentos constantes e perdas de progresso. Situações como essa podem ser devastadoras tanto para a experiência dos jogadores quanto para a reputação das empresas. Neste artigo, quero discutir o que é escalabilidade em jogos, por que ela é tão importante, como o caso de Animal Jam ilustra esses desafios — e o que pode ser feito para resolvê-los.

📌 O que é escalabilidade em jogos?

Escalabilidade é a capacidade de um sistema lidar com o crescimento de forma eficiente. No contexto de jogos, isso significa:

• Suportar mais jogadores simultâneos;
• Processar mais dados em tempo real;
• Aumentar a capacidade de servidores sem prejudicar o desempenho;
• Manter baixa latência e alta disponibilidade, mesmo em horários de pico ou em eventos especiais.

Em outras palavras, um jogo escalável cresce junto com sua comunidade — sem desmoronar quando a base de usuários dobra de tamanho ou quando há um evento global que atrai milhões de jogadores ao mesmo tempo.

🔍 Tipos de escalabilidade aplicáveis em jogos

Existem diferentes formas de tornar um sistema escalável. Em jogos, as mais comuns são:

🔹 1. Escalabilidade vertical (scale-up)

Adiciona-se mais capacidade a um servidor individual (CPU, RAM, disco). Funciona bem em curto prazo, mas tem limites físicos e é mais cara.

🔹 2. Escalabilidade horizontal (scale-out)

Multiplica-se a infraestrutura: vários servidores processam o mesmo tipo de carga simultaneamente. Ideal para jogos com arquitetura distribuída.

🔹 3. Escalabilidade funcional

Separa-se o sistema em partes independentes: autenticação, matchmaking, loja, inventário, chat, etc. Cada uma pode crescer de forma autônoma conforme a demanda.

🔹 4. Escalabilidade geográfica

Distribui-se servidores ao redor do mundo, reduzindo a latência para jogadores em diferentes regiões.

🐾 O que aconteceu com Animal Jam em 2025?

Animal Jam é um jogo multiplayer online educativo voltado ao público infantil, conhecido por seus gráficos amigáveis e mecânicas leves. Em 2025, no entanto, a comunidade começou a relatar:

• Quedas frequentes de servidor;
• Longos tempos de carregamento;
• Travamentos em massa durante interações simples;
• Perda de dados ou progresso do jogador;
• Erros de conexão mesmo com internet estável.

Esses sintomas sugerem um problema estrutural de escalabilidade.

🧯 Possíveis causas dos problemas

🔸 Arquitetura monolítica

Se o backend do jogo ainda for baseado em uma arquitetura monolítica — onde todas as funções estão juntas em um só sistema — qualquer aumento na carga compromete o todo. Um erro em uma função pode derrubar o servidor inteiro.

🔸 Servidores sobrecarregados

A tentativa de escalar verticalmente (aumentar a potência de uma única máquina) tem limite. Se o número de jogadores aumenta sem que novos servidores sejam adicionados (escalabilidade horizontal), o sistema entra em colapso.

🔸 Falta de balanceamento de carga

Sem uma distribuição eficiente de usuários entre instâncias ou regiões, alguns servidores ficam sobrecarregados enquanto outros estão subutilizados.

🔸 Banco de dados centralizado

Um único banco de dados pode se tornar um gargalo se todas as requisições (logins, compras, dados do jogador) passarem por ele. A lentidão se propaga pelo sistema inteiro.

🛠️ O que a empresa pode fazer para resolver?

O caso de Animal Jam não é único — e felizmente, tem solução. Aqui vão algumas medidas práticas que poderiam ser adotadas pela WildWorks:

✅ 1. Migrar para uma arquitetura de microserviços

Separar o backend em componentes menores e independentes (login, inventário, matchmaking, etc.). Isso permite escalar apenas o que está em alta demanda, sem afetar todo o sistema.

✅ 2. Implementar escalabilidade horizontal automatizada

Adotar soluções de auto-scaling na nuvem (como AWS EC2, GCP Compute Engine, Azure VM Scale Sets) para criar novas instâncias de servidor conforme a carga aumenta.

✅ 3. Usar filas e eventos assíncronos

Operações pesadas como salvar progresso ou gerar relatórios podem ser feitas em segundo plano, sem travar a interação principal do jogador.

✅ 4. Cache inteligente e CDN

Conteúdos estáticos como imagens, sons e animações devem ser servidos por redes de distribuição (CDNs) e não diretamente do servidor de aplicação.

✅ 5. Sharding e replicação de banco de dados

Dividir dados por região, tipo de jogador ou outros critérios evita sobrecarga em um único banco e aumenta a resiliência.

✅ 6. Testes de carga contínuos

Simular o comportamento de milhares de jogadores com ferramentas como k6, Locust ou Artillery permite identificar gargalos antes que afetem o ambiente real.

📊 Outras empresas que enfrentaram (ou resolveram) esse problema

• Fortnite (Epic Games): adotou arquitetura em nuvem com auto-scaling e edge servers.
• League of Legends (Riot): usou sharding e balanceamento regional para evitar colapsos.
• Among Us: enfrentou sérios problemas de servidor após viralização em 2020, mas se reestruturou com suporte escalável e servidores dedicados.

💭 Reflexão final

A escalabilidade é invisível aos olhos do jogador, mas fundamental para garantir que a mágica do jogo aconteça sem interrupções. O colapso de servidores em Animal Jam serve como um alerta para todas as empresas que investem em jogos online: não basta ter um bom conceito — é preciso preparar a infraestrutura para o crescimento.

Investir em escalabilidade desde os primeiros estágios de desenvolvimento é mais barato, mais seguro e mais sustentável do que tentar apagar incêndios depois.

Como desenvolvedora em formação e apaixonada por IA, acredito que combinar boas práticas de engenharia com inteligência adaptativa será o futuro dos jogos estáveis e dinâmicos.

Engenheira de Software e Estudante de Especialização em IA Aplicada na UFPR

“Dói muito pensar onde essas pessoas estão. Meu coração aperta.”

— Costanza, estudante de Inteligência Artificial na UFPR

Todos os anos, milhares de pessoas desaparecem no Brasil — e a maioria delas permanece sem resposta. Para as famílias, o tempo congela. A ausência vira rotina. Mas, nos últimos anos, a tecnologia tem começado a agir onde a esperança quase já não alcançava. A inteligência artificial (IA) tem sido cada vez mais usada para localizar pessoas desaparecidas: reconhecendo rostos, cruzando dados e criando imagens que atravessam o tempo.

Como estudante de IA pela Universidade Federal do Paraná (UFPR), vejo nesse campo uma das formas mais humanas de aplicar programação e ciência de dados: não para prever o futuro, mas para reconstruir histórias interrompidas.

— -

O desaparecimento: um problema global e local

De acordo com a [International Missing Persons Wiki](https://int-missing.fandom.com/wiki/International_Missing_Persons_Wiki), uma pessoa desaparecida é aquela cuja localização ou condição é desconhecida. Isso pode envolver sequestros, fugas voluntárias, tráfico humano, acidentes ou até mesmo falhas em sistemas de registro. O problema é global: em 2023, a Interpol registrava dezenas de milhares de casos abertos em todo o mundo.

No Brasil, os números impressionam. Segundo o Fórum Brasileiro de Segurança Pública, foram **mais de 80 mil desaparecimentos registrados apenas em 2023**. Muitos casos nunca são resolvidos; outros demoram anos até que uma pista — ou a tecnologia — faça a diferença.

Em Curitiba e no Paraná, diversos casos ganharam atenção nas últimas décadas e permanecem na memória:

- Guilherme Caramês, desaparecido em 1991, motivou a criação do Sicride (Serviço de Investigação de Crianças Desaparecidas) no Paraná;

- Casos como os de Rodrigo Novick, Ewerton Gonçalves e Osnei Ranea mostram que o problema se repete ao longo do tempo;

- Mais recentemente, em 2025, três irmãs de 0, 2 e 6 anos desapareceram em Curitiba, reacendendo o alerta para a necessidade de ação mais rápida e eficaz.

Diante disso, qualquer ferramenta que ajude a cruzar informações, comparar rostos ou dar visibilidade a casos pode significar uma nova chance para as famílias.

— -

IA e programação: como a tecnologia pode ajudar

Na prática, a IA tem potencial para acelerar buscas, cruzar informações e até **simular o envelhecimento facial de quem desapareceu há muitos anos. Não se trata de substituir o trabalho humano, e sim de apoiá-lo com dados e padrões que seriam impossíveis de processar manualmente.

Algumas formas concretas de aplicação incluem:

Reconhecimento facial com Python

Usando bibliotecas como OpenCV, face_recognition, dlib ou modelos mais avançados como InsightFace, é possível criar sistemas que extraem “assinaturas” matemáticas do rosto (os chamados *embeddings*). Esses vetores numéricos permitem comparar uma foto antiga com milhares de imagens de bancos de dados ou câmeras, buscando a maior similaridade. Em outras palavras: o algoritmo não “vê” o rosto como nós; ele o transforma em números e compara quem é “mais parecido” com quem.

Envelhecimento digital com redes neurais

GANs (redes adversariais generativas) são capazes de gerar uma projeção atualizada da aparência de uma pessoa desaparecida com base em fotos da infância ou da adolescência. Assim, campanhas podem divulgar não só a última foto conhecida, mas uma imagem que se aproxime de como a pessoa poderia estar hoje.

Análise de redes sociais e câmeras urbanas

O cruzamento de dados com NLP, localização geográfica e bancos públicos pode apontar pistas úteis. Em alguns países, apps conectam imagens de câmeras de segurança a bases de desaparecidos, gerando alertas quando há possível correspondência.

Integração com sistemas governamentais

Criar APIs ou dashboards interativos que atualizam informações de desaparecimentos em tempo real permite que ONGs, polícias e cidadãos trabalhem com os mesmos dados, reduzindo duplicidade e atrasos.

Como programadora, percebo que não se trata apenas de “criar código”, mas de usar código para criar reencontros.

— -

FindThem: um projeto de TCC na UFPR

Durante a Especialização em Inteligência Artificial na UFPR, desenvolvi o FindThemcomo Trabalho de Conclusão de Curso (TCC). O objetivo é colocar em prática exatamente o que este artigo descreve: um sistema assistido por IA para apoiar a identificação de pessoas desaparecidas usando reconhecimento facial e visão computacional.

O FindThem funciona em três eixos:

1. Registro de casos — A família ou uma autoridade cadastra a pessoa desaparecida com nome, foto e dados (data do desaparecimento, última vez vista, contato). A foto é processada e o rosto é convertido em um vetor numérico (embedding), que fica armazenado para comparação.

2. Avistamentos — Qualquer pessoa pode enviar uma foto (por exemplo, de uma câmera de segurança ou de um local público) com notas e localização. O sistema extrai os rostos da imagem e compara com todos os casos registrados, gerando uma lista de possíveis correspondências com um score de similaridade.

3. Matches — Os resultados são exibidos em uma interface tipo “arquivo de caso”: cada match mostra a pessoa desaparecida, a imagem do avistamento e o grau de similaridade. Assim, um operador humano pode priorizar as melhores pistas e acionar as autoridades quando fizer sentido.

A arquitetura inclui front-end em React (cadastro, upload de fotos, visualização de matches), API em Python (FastAPI) para processamento das imagens e extração de embeddings, e busca por similaridade em base vetorial. O sistema foi pensado para poder ser implantado em ambiente controlado (por exemplo, em parceria com um órgão como o Sicride), sempre com revisão humana dos resultados: a IA sugere; o humano decide.

O projeto está disponível em repositório aberto e pode ser implantado em plataformas como a Vercel, com banco de dados e armazenamento de imagens na nuvem. Para mim, o FindThem é a materialização do que acredito: usar a IA com propósito, ética e sensibilidade para reconectar famílias e devolver histórias que pareciam perdidas no tempo.

— -

Casos reais: IA em ação

Piracanjuba e o projeto “Desaparecidos”

Em 2024, a marca Piracanjuba se uniu ao grupo Mães da Sé para aplicar IA em uma campanha de comoção nacional. A proposta foi simples e poderosa: usar algoritmos para envelhecer digitalmente rostos de crianças desaparecidas e estampar essas imagens em caixas de leite. A campanha viralizou, gerou novas denúncias e trouxe esperança para famílias que, há décadas, não recebiam novidades.

Family Faces e Microsoft

Outro exemplo relevante é o app Family Faces, desenvolvido no Brasil com apoio da Microsoft, que utiliza IA para reconhecer padrões faciais e cruzá-los com bancos de dados de desaparecidos. Com ele, centenas de famílias já reencontraram entes queridos, inclusive pessoas desaparecidas há mais de 10 anos.

No mundo: IA como ferramenta de buscas

Na Rússia, o app FindFace foi usado para localizar pessoas desaparecidas com base em imagens de câmeras de segurança e redes sociais. Na Europa, drones autônomos com câmeras térmicas e IA são empregados em áreas florestais e zonas de desastre para encontrar sobreviventes e desaparecidos — uma tecnologia em rápida expansão.

— -

Ética, privacidade e limites

Aplicar IA a dados sensíveis como rostos e desaparecimentos exige cuidado. No FindThem, por exemplo, há um aviso de privacidade e ética antes do uso: as imagens são processadas apenas para comparação e possíveis correspondências; os resultados são indicativos e precisam de revisão humana; e o sistema não deve ser usado para vigilância em massa ou fins incompatíveis com os direitos das pessoas.

A LGPD e as boas práticas de proteção de dados devem guiar qualquer projeto nessa área. A tecnologia é uma aliada quando usada com transparência, consentimento e respeito às famílias.

— -

Conclusão: IA com propósito

A inteligência artificial tem potencial para transformar a vida das pessoas — e não só através de inovação comercial. Quando usada com propósito, ética e sensibilidade, ela pode reconectar famílias, restaurar identidades e devolver histórias que pareciam perdidas no tempo.

Como estudante de IA na UFPR, quero usar a programação não só para criar tecnologias de ponta, mas também para construir pontes entre os dados e os afetos — entre os algoritmos e as pessoas. O FindThem é um passo nessa direção: da sala de aula para um sistema que, espero, possa um dia apoiar buscas reais.

“Eu ainda não sou mãe, mas imagino o quanto dói não saber onde seu filho está, o que aconteceu. A IA pode ser sim nossa aliada.”

— Costanza, estudante de Inteligência Artificial na UFPR

— -

*O FindThem é um projeto de TCC da Especialização em IA da UFPR. Repositório: [GitHub — Find-Them](https://github.com/Costanza22/Find-Them).*

Por Costanza Pasquotto Assef | Engenheira de Software e Estudante de Especialização em IA Aplicada na UFPR

“Katrina wasn’t just a hurricane. It was a system failure.”

”In the United States, during a disaster, no one thinks about Black children.”

— Frases marcantes do documentário Filhos do Katrina

Furacão Katrina como estudo de caso

Acredito que a tecnologia, especialmente a IA, pode (e deve) ser usada não apenas para inovação, mas para reconstrução — inclusive de memórias. Ao estudar grandes desastres como o Furacão Katrina, percebo o quanto os dados podem ser ferramentas de empatia, de denúncia e de transformação social.

Em 29 de agosto de 2005, o Furacão Katrina atingiu o sul dos Estados Unidos, devastando a costa do Golfo, especialmente Nova Orleans. Com ventos que ultrapassaram os 280 km/h e o rompimento de diques que deveriam proteger a cidade, mais de 1.800 pessoas morreram, milhares ficaram desabrigadas e um trauma coletivo se enraizou na história americana.

Duas décadas depois, o Katrina ainda é uma ferida aberta — mas agora recontada e reinterpretada por diferentes vozes, linguagens e tecnologias. Enquanto documentários como Closed for Storm e Filhos do Katrina revelam o impacto humano e social da tragédia, a inteligência artificial (IA) surge como uma ferramenta para compreender, prever e, paradoxalmente, lembrar.

A Catástrofe em Câmera Lenta: o abandono do povo

O documentário Closed for Storm (dirigido por Jake Williams) tem como símbolo o Six Flags New Orleans — um parque de diversões que nunca mais reabriu após o furacão. Mais do que ruínas, ele representa sonhos interrompidos, investimentos abandonados e a negligência com comunidades marginalizadas. O parque, ironicamente fechado “por causa da tempestade”, virou um monumento ao descaso.

Já Filhos do Katrina, da HBO Max, oferece uma abordagem profundamente íntima e emocional. Acompanhamos crianças que vivenciaram o desastre crescerem entre traumas, deslocamentos e resiliência. A narrativa expõe como o Katrina não foi apenas um fenômeno natural, mas um desastre político e social. A catástrofe não foi o furacão em si, mas a resposta — ou a falta dela.

IA, dados e desastres: como a tecnologia lê tragédias

Hoje, a inteligência artificial desempenha um papel crescente na análise de desastres naturais. Algoritmos processam dados meteorológicos, imagens de satélite, relatórios de emergência e até postagens em redes sociais para prever padrões, identificar áreas de risco e otimizar respostas humanitárias.

Durante o Katrina, esses sistemas ainda eram embrionários. Mas o que aconteceria se a IA de hoje existisse naquela época?

• Sensoriamento remoto com aprendizado de máquina poderia ter identificado falhas estruturais nos diques com mais antecedência.
• Modelos preditivos poderiam ter simulado cenários de alagamento com mais precisão, salvando vidas.
• Processamento de linguagem natural (PLN) pode hoje extrair sentimentos, necessidades e padrões de desinformação a partir de textos em tempo real — algo crucial durante crises.

Esses sistemas aprendem com eventos passados. O Katrina se tornou um “caso de treinamento” para muitas ferramentas de IA aplicadas à gestão de risco e emergência. A máquina aprende com o sofrimento humano, não no sentido de sentir, mas de reconhecer padrões. E com isso, surgem dilemas éticos: quem são as vozes ouvidas nos dados? O que fica invisível nos algoritmos?

Dados também têm memória — mas e a empatia?

A IA pode aprender que Nova Orleans foi inundada, que bairros negros e pobres foram os mais afetados, que o parque nunca mais abriu, que milhares de famílias nunca mais voltaram para casa. Mas ela não sente o que uma criança sentiu ao perder seu lar, como mostraram os depoimentos em Filhos do Katrina.

Documentários e IA se cruzam aqui: ambos constroem narrativas, mas de formas diferentes. A diferença é que um cineasta escolhe a lente e o enquadramento; um algoritmo aprende com o que foi alimentado. A pergunta é: estamos alimentando essas tecnologias com empatia, contexto e representatividade?

E onde entra a programação nisso tudo?

Toda análise feita por IA parte de código — linhas escritas por pessoas que precisam tomar decisões o tempo todo: quais dados usar, o que considerar ruído, como interpretar resultados. A linguagem predominante nesse ecossistema é o Python, graças à sua versatilidade e às bibliotecas poderosas:

• pandas e numpy para tratamento de dados.
• scikit-learn para construir modelos preditivos de regressão ou classificação (ex: prever danos materiais com base em dados climáticos).
• geopandas, folium e shapely para visualizar e analisar mapas geoespaciais.
• transformers (Hugging Face) para aplicar PLN em textos extraídos de redes sociais.
• PyTorch e TensorFlow para construir redes neurais complexas, como CNNs para classificar imagens aéreas de destruição.

🌪️ Exemplo: Um modelo pode ser treinado para identificar automaticamente zonas de risco de alagamento com base em imagens de satélite, comparando o que existia antes e depois da passagem de um furacão.

Dados reais: o que o Kaggle ensina sobre o Katrina

O Kaggle é uma plataforma global onde cientistas de dados compartilham modelos, notebooks e datasets — e o Katrina é tema recorrente por lá. Entre os datasets disponíveis, destacam-se:

• Hurricane Katrina Disaster Response Data: contém informações de evacuação, vítimas, infraestrutura, centros de abrigo e linhas de ajuda emergencial.
• NOAA Tropical Cyclone Tracks: permite analisar a rota de furacões históricos com foco em intensidade, duração e impacto.
• FEMA Damage Assessment Data: usado para treinar modelos que estimam a severidade dos danos em tempo real.

Esses datasets não são apenas números — são histórias codificadas. Cada linha de uma planilha representa uma pessoa, uma casa, um trauma.

Projetos reais com impacto social

Diversas iniciativas demonstram como a ciência de dados e a IA podem servir à justiça climática e à resposta humanitária:

• Data Science for Social Good (DSSG): treina profissionais para aplicar ciência de dados em contextos sociais, inclusive análise de desastres.
• AI for Disaster Response (Meta, Google AI): foca em analisar postagens em redes sociais para direcionar equipes de socorro.
• NASA Project NOAH: reconstrói digitalmente cidades destruídas usando IA para fins de planejamento urbano e prevenção.

Conclusão: o Katrina como advertência e aprendizado

O Furacão Katrina não foi apenas uma tragédia natural. Ele escancarou desigualdades históricas, racismo estrutural, falhas de governo e a resiliência de uma população abandonada. Agora, à medida que a inteligência artificial entra em cena, temos uma nova chance de olhar para o passado com mais precisão — mas também com mais responsabilidade.

Programar não é neutro. Os algoritmos que criamos, os dados que escolhemos usar (ou não), as análises que conduzimos — tudo isso compõe uma nova narrativa. Uma narrativa que pode servir para prevenção e reconstrução, ou para invisibilizar ainda mais os mesmos de sempre.

Assistir a Closed for Storm é encarar a ruína física. Assistir a Filhos do Katrina é ouvir a ruína emocional. Usar IA nesses contextos é, ou deveria ser, uma ponte entre os dados e a dignidade.