Oferecido por
Em uma ocorrência de deslizamento, enchente, rompimento de barreira, vazamento de produto químico perigoso ou qualquer outro evento de origem ambiental ou tecnológica, equipes de resposta operam sob pressão extrema. Cada minuto importa. Entretanto, muitas vezes a equipe de resgate descobre apenas no local do chamado que existe uma pessoa que não consegue se deslocar sozinha, depende de oxigênio, precisa de um cuidador, não escuta alertas sonoros, tem baixa visão ou necessita de equipamentos específicos para ser retirada com segurança.
Como consequência, pessoas com deficiência chegam a ser 2 a 4 vezes mais propensas a sofrer lesões ou falecer em desastres, segundo os dados do Escritório das Nações Unidas para a Redução do Risco de Desastres (UNDRR). Em estudos de campo, como o do ciclone tropical Pam, pessoas com deficiência registraram probabilidade 2,45 vezes maior de sofrer ferimentos do que a população sem deficiência.
No Brasil, o Censo 2022 do IBGE registrou 14,4 milhões de pessoas com deficiência, o equivalente a 7,3% da população com dois anos ou mais. Em um país exposto a desastres ambientais, riscos tecnológicos e vulnerabilidades urbanas, esse dado deixa de ser apenas uma informação demográfica. Ele se torna uma questão de proteção civil.
Resolver esse problema é a proposta da Solução Digital P2R3in (Prevenção, Preparação e Resposta Rápida para Resgate Inclusivo), projeto desenvolvido para apoiar a prevenção, preparação e resposta rápida no resgate de pessoas com deficiência, mobilidade reduzida e acamadas em situações de emergência. A iniciativa, que envolve a OceanPact, o Projeto Incluir Petrópolis e a Infobase, está em fase de homologação e o seu piloto será testado em Petrópolis, cidade no Rio de Janeiro marcada pela ocorrência de eventos extremos com severos impactos para a população.
O problema que o projeto busca resolver não está apenas na falta de tecnologia. Está na ausência de informação estruturada antes da emergência acontecer.
A proposta do P2R3in é permitir que pessoas com deficiência, mobilidade reduzida, acamados, cuidadores ou responsáveis cadastrem informações essenciais sobre condições de saúde, tipo de deficiência, mobilidade, dependência de equipamentos e necessidades específicas. Em emergência, o acionamento chega ao painel de Comando e Controle com geolocalização e perfil de necessidade. Fora da emergência, os dados podem apoiar análises territoriais, revisão de Planos de Contingência e políticas públicas de prevenção.
A lógica é simples, mas muda a natureza da resposta: a pessoa deixa de ser uma exceção descoberta no pior momento possível e passa a ser considerada desde o primeiro segundo.
Inovar não é começar pela tecnologia
Um dos aprendizados mais relevantes do projeto é que um produto digital inclusivo não nasce da pergunta “qual produto devemos criar?”, mas da pergunta “qual lacuna os atuais sistemas de prevenção e resposta a emergência não conseguem prever?”.
Segundo Arthur Kós, diretor de Inovação da OceanPact, o processo de escuta precisou considerar duas camadas de complexidade: a primeira envolve a diversidade das limitações dos usuários e a segunda envolve questões relativas ao planejamento do resgate de pessoas vulneráveis.
Só quando essas duas camadas foram sobrepostas o problema se tornou mais claro: como uma pessoa com deficiência se move, pede ajuda e é reconhecida por um sistema de resposta em uma situação de desastre?
Essa pergunta desloca o centro do projeto: em vez de criar uma ferramenta “para” pessoas com deficiência, a equipe buscou construir uma solução “com” elas. A diferença não é semântica. Projetar para alguém parte de hipóteses externas; projetar com alguém obriga o time a confrontar barreiras que não aparecem em uma sala de desenvolvimento.
Isso também exigiu desaprender premissas comuns em projetos de tecnologia. A primeira foi a tendência de desenhar a solução a partir do operador do sistema, isto é, da lógica de Comando e Controle. Essa perspectiva é necessária, mas insuficiente quando o objetivo é inclusão. A segunda foi tratar pessoas com deficiência como um perfil único. A terceira foi assumir que a tecnologia, por si só, resolveria o problema.
No dia a dia das comunidades, o fluxo aparentemente simples de um aplicativo se desdobra em questões concretas. Quem ajuda a preencher o cadastro de uma pessoa que não tem celular próprio? Como incluir alguém com baixa alfabetização digital? Quem explica a finalidade do cadastro para uma família que tem medo de declarar uma deficiência por receio de estigma? Como garantir que a informação esteja atualizada quando uma condição de saúde, endereço ou necessidade de equipamento muda?
Essas perguntas mostram que o produto digital é apenas uma parte da infraestrutura. A adesão depende de confiança, presença comunitária e legitimidade local.
Da acessibilidade à inclusão
Há uma diferença importante entre uma solução acessível e uma solução inclusiva.
Acessibilidade envolve requisitos técnicos indispensáveis: contraste adequado, compatibilidade com leitor de tela, área de toque suficiente, estrutura semântica correta, linguagem compreensível e aderência a diretrizes como a Web Content Accessibility Guidelines – Diretrizes de Acessibilidade para Conteúdo da Web (WCAG). Sem isso, a tecnologia exclui parte dos usuários no ponto de entrada.
Mas a inclusão vai além. Uma solução inclusiva considera o contexto de uso, o estado emocional da pessoa, a presença de cuidadores, o repertório digital, o vocabulário, a confiança nas instituições e a capacidade real de acionar ajuda em um momento de estresse.
No P2R3in, isso significou desenhar a experiência para múltiplos perfis ao mesmo tempo: a pessoa com deficiência que faz o próprio cadastro, o cuidador que cadastra alguém sob seus cuidados, o agente comunitário que apoia a adesão e o resgatista que precisa decidir rapidamente em campo.
Um exemplo desse aprendizado apareceu no cadastro de cuidadores. Inicialmente, a equipe havia desenhado um fluxo independente, com telas próprias. Na prática, isso duplicava a experiência e aumentava a carga cognitiva. A solução foi incorporar o cuidador dentro do fluxo principal, como uma camada do mesmo cadastro. Assim, uma pessoa pode registrar uma PcD sob seus cuidados sem que o produto se fragmente em jornadas paralelas.
Essa decisão resume uma regra importante para inovação social: personalização não pode significar complexidade infinita. O desafio é reconhecer diferenças sem transformar cada diferença em um novo obstáculo de uso.
Dados que servem à urgência e ao planejamento
A coleta de dados em uma plataforma voltada a populações vulneráveis exige uma fronteira clara entre proteção e vigilância. O cadastro precisa ser voluntário, baseado em consentimento informado e transparente quanto à finalidade.
No modelo do P2R3in, os dados operam em duas camadas. A primeira é operacional: em uma emergência, a equipe recebe informações que ajudam a priorizar e qualificar o resgate. A segunda é analítica: fora da emergência, a distribuição geográfica das pessoas cadastradas pode indicar áreas de maior vulnerabilidade, apoiar Planos de Contingência e orientar políticas públicas.
Essa separação é decisiva. O mesmo dado que pode salvar uma vida em uma ocorrência também pode melhorar a preparação de uma cidade antes da próxima crise. Mas, para isso, a governança precisa ser explícita: quem acessa, para qual finalidade, em que momento e com quais limites.
Outro ponto sensível é a atualização. Um cadastro feito uma única vez pode se tornar um risco se criar a ilusão de informação confiável onde a realidade já mudou. Endereços mudam. Condições de saúde evoluem. Equipamentos deixam de ser necessários ou passam a ser indispensáveis. Cuidadores podem mudar.
Por isso, a manutenção da base precisa combinar mecanismos digitais de revisão periódica, atuação de agentes comunitários e, quando possível, integração com bases públicas existentes. Ainda assim, nenhuma dessas frentes substitui o elemento mais difícil de escalar: confiança.
Uma pessoa só atualiza seus dados se acreditar que aquilo terá utilidade real, não será usado contra ela e poderá produzir uma resposta mais adequada quando necessário.
O desafio de encaixar o novo no que já funciona
Soluções de impacto raramente partem de uma página em branco. Em emergências, isso é ainda mais verdadeiro. Defesa Civil, Bombeiros e órgãos de resposta já operam com protocolos, responsabilidades e fluxos testados. Qualquer tecnologia que tente substituir esse arcabouço tende a encontrar resistência e, muitas vezes, com razão. O caminho adotado pelo P2R3in foi complementar o que já existe.
A equipe estudou Planos de Contingência, o programa Awareness and Preparedness for Emergencies at Local Level ou Alerta e Preparação de Comunidades para Emergências Locais (APELL) da ONU e protocolos como o P2R2, voltado à prevenção, preparação e resposta rápida a emergências ambientais com produtos químicos perigosos. A ideia foi desenhar uma camada adicional de visibilidade para pessoas com deficiência, sem competir com sistemas já usados em campo.
Esse ponto é central para projetos de inovação aplicada. O sucesso não depende apenas de o produto funcionar tecnicamente. Depende de ele caber na rotina institucional, respeitar responsabilidades, reduzir fricção operacional e demonstrar valor concreto para equipes que lidam com vidas.
A maior resistência, até aqui, não parece ser técnica. É institucional. Isso não significa oposição à inclusão, mas cautela diante de qualquer solução nova em ambientes de alto risco. Nesses contextos, inovação precisa provar que melhora a resposta sem aumentar a complexidade.
Petrópolis como caso em construção
Petrópolis ainda não é um caso replicável. É um caso em construção.
Essa distinção importa porque projetos de impacto social costumam ser apresentados como modelos prontos para escala antes de terem sido suficientemente testados. No P2R3in, a fase atual envolve a validação de usabilidade, alinhamento com protocolos e preparação para ida a campo.
A escolha de Petrópolis tem peso simbólico e operacional. A cidade carrega marcas de desastres recentes e tem uma Defesa Civil com experiência acumulada em prevenção e resposta. A imersão no território envolveu reuniões presenciais, escuta com agentes de campo, reconhecimento dos Núcleos Comunitários de Defesa Civil e mapeamento de rotinas reais.
Esse processo ajuda a ajustar a tecnologia às condições do território, não o contrário.
Antes do lançamento, três blocos ainda precisam ser validados. O primeiro envolve testes de usabilidade com diferentes perfis: pessoas com deficiência que se cadastram sozinhas, cuidadores, cidadãos sem deficiência e operadores do painel. O segundo envolve simulados de desastres ambientais ou tecnológicos, ambiente no qual integração com protocolos e tempo de resposta podem ser observados sem o custo de uma ocorrência real. O terceiro envolve a validação dos materiais de comunicação e da estratégia de engajamento comunitário.
Não basta o aplicativo funcionar. A adesão precisa funcionar.
A escala depende de instituições, não só de software
O desafio de escala é talvez o mais complexo. Desenvolver uma plataforma replicável é diferente de fazê-la operar em municípios com capacidades institucionais, sistemas, equipes e maturidade digital muito distintas.
Em uma cidade, pode haver integração com Defesa Civil, agentes comunitários ativos e base pública organizada. Em outra, pode haver baixa digitalização, desconfiança da população e falta de rotina de atualização. Em uma terceira, o principal risco pode ser ambiental; em outra, tecnológico; em outra, combinado.
Por isso, uma aplicação universal não pode ser uma aplicação genérica. Ela precisa ter núcleo comum e capacidade de adaptação local. O núcleo comum envolve princípios de acessibilidade, consentimento, dados estruturados, integração com protocolos e painel operacional. A adaptação local envolve linguagem, redes comunitárias, fluxos institucionais e prioridades de risco.
Essa tensão entre personalização e escala é uma das perguntas centrais da inovação de impacto. Escalar não é apenas copiar uma solução. É replicar um método de escuta, adaptação e governança.
O que esse projeto ensina sobre inovação orientada a impacto social
O P2R3in ainda precisa ser testado em condições reais para demonstrar seus efeitos. O sucesso, como aponta Chen Li Cheng, fundador do Projeto Incluir Petrópolis e gerente de operações da OceanPact, será medido por dois critérios: salvar vidas e colaborar para políticas públicas inclusivas.
Essa definição é importante porque reposiciona a inovação. O objetivo não é lançar um produto. É reduzir uma desigualdade concreta no atendimento emergencial.
O projeto também aponta para uma agenda mais ampla: o uso de dados para tornar populações vulneráveis visíveis sem transformá-las em objetos de vigilância; a aplicação de tecnologia para qualificar serviços públicos sem substituir protocolos existentes; e a construção de soluções inclusivas que começam no usuário.
Em um momento em que muitas organizações tratam inovação como velocidade de entrega, o P2R3in sugere outra métrica: a capacidade de redesenhar sistemas para que eles reconheçam pessoas que antes ficavam fora do campo de abrangência.
Nesse sentido, a inovação orientada a impacto não pergunta apenas o que a tecnologia pode fazer. Pergunta quem ela passa a considerar, quem ela protege melhor e quais decisões se tornam possíveis quando a informação certa chega antes da emergência.
MIT Technology Review