top of page

Notícias de Tecnologia de Shenzhen 119: um anúncio no navegador bloqueou o envio de um vídeo de emergência

O Shenzhen 119 despachou bombeiros imediatamente, mas um anúncio no navegador atrasou em cerca de 30 segundos o envio opcional, por uma moradora, de um vídeo da cena do incêndio. Esta notícia de tecnologia revela um conflito entre o design de serviços de emergência e o software comercial que o cerca.

O anúncio não veio do corpo de bombeiros de Shenzhen. Segundo o departamento, o navegador móvel da moradora o exibiu ao abrir um link de emergência enviado por mensagem de texto.

Essa distinção isenta o serviço de emergência de vender publicidade. Ela não resolve o problema mais amplo de segurança.

Uma agência pública pode criar uma página de envio limpa e rápida. Ainda assim, o usuário pode chegar a ela por um navegador, sistema operacional, cliente de mensagens ou manipulador de links controlado por outra empresa.

Cada camada pode introduzir um anúncio, solicitação de permissão, redirecionamento, aviso de atualização ou interface confusa. Durante uma emergência, qualquer interrupção passa a fazer parte da experiência do serviço público.

Portanto, a disputa central não é Shenzhen 119 contra uma empresa de navegadores identificada. O navegador envolvido não foi nomeado publicamente.

O verdadeiro adversário é a promessa de uma rota direta de emergência diante da realidade de um ambiente móvel financiado por publicidade. Esse ambiente não compreende de forma confiável quando um link comum se transforma em uma tarefa crítica para a segurança.

O que aconteceu quando o link do incêndio foi aberto

A resposta ao incêndio começou sem esperar, mas as informações de apoio entraram em um desvio comercial evitável.

Uma moradora de Shenzhen, identificada pela mídia chinesa pelo sobrenome Zhang, teria visto chamas saindo da varanda de uma vizinha. Ela ligou para o número de emergência dos bombeiros da China, 119.

Em seguida, uma atendente enviou uma mensagem de texto com um link. A atendente pediu que ela enviasse um vídeo da cena para que as equipes pudessem avaliar melhor o incêndio.

Quando Zhang selecionou o link, seu celular abriu um aplicativo de navegador. Um anúncio de abertura em tela cheia apareceu antes que ela chegasse à página de envio do corpo de bombeiros.

Zhang teria tentado fechar o anúncio, mas fechou acidentalmente a janela do navegador. Ela voltou à mensagem de texto, selecionou o link novamente e encontrou o anúncio mais uma vez.

Na segunda tentativa, ela encontrou o controle para pular o anúncio e concluiu o envio. Um relato posterior detalhado, atribuído ao Southern Metropolis Daily, estimou o atraso em cerca de 30 segundos.

Um comentário publicado posteriormente descreveu a interrupção como tendo durado quase um minuto. A diferença não altera a sequência subjacente, mas deve evitar uma precisão enganosa.

Nenhum dos relatos estabeleceu a identidade do navegador, do fornecedor do anúncio ou do anunciante. Nenhuma evidência pública analisada para esta reportagem mostra que o corpo de bombeiros controlava o anúncio.

O centro de comando dos bombeiros de Shenzhen afirmou que recebeu o relato por telefone e iniciou imediatamente os procedimentos de despacho. As equipes se deslocaram enquanto a moradora lidava com a solicitação de vídeo.

O departamento descreveu o vídeo como informação complementar. Afirmou que os socorristas não esperaram pelo envio antes de sair do quartel.

Outro vizinho também havia ligado para o 119, segundo os relatos. Os bombeiros chegaram rapidamente, e o incidente não teve consequências graves relatadas.

Esses fatos importam porque a versão provocativa da história pode induzir ao erro. A moradora não precisou assistir a um anúncio antes que o Shenzhen 119 aceitasse sua chamada de emergência.

Ela encontrou o anúncio durante uma etapa digital secundária. A etapa pretendia fornecer aos socorristas mais informações visuais enquanto a resposta já estava em andamento.

Ainda assim, “secundária” não significa trivial. Um vídeo pode mostrar densidade de fumaça, localização das chamas, acesso ao prédio, estruturas expostas e riscos que pessoas em ligação têm dificuldade de descrever.

Essas informações podem ajudar um centro de comando a refinar sua avaliação. Também podem ajudar as equipes que chegam a entender quais equipamentos ou abordagem a cena exige.

Portanto, a interrupção no navegador não atrasou o despacho, com base na declaração do departamento. Ela atrasou a entrega de um contexto operacional potencialmente útil.

Essa distinção é a base de uma análise responsável. Ela evita exagerar o resultado, ao mesmo tempo que reconhece que ocorreu uma falha real de design.

Por que esta notícia de tecnologia importa além de um único anúncio

Uma jornada crítica para a segurança é tão confiável quanto a camada de software menos previsível entre o usuário e o serviço.

Órgãos governamentais usam cada vez mais links da web para coletar fotos, vídeos, formulários, localizações e outras informações estruturadas. Os links oferecem ampla compatibilidade sem exigir que cada morador instale um aplicativo dedicado.

Essa flexibilidade cria uma dependência. O serviço não controla todos os componentes envolvidos na abertura do destino.

Uma mensagem de texto pode iniciar o navegador padrão do celular. O navegador pode exibir uma tela de abertura antes de renderizar a página solicitada.

Em vez disso, o sistema operacional pode apresentar um seletor de aplicativos, aviso de segurança ou solicitação de permissão. As condições de rede podem acrescentar outro atraso.

Equipes comuns de produto tratam essas interrupções como problemas de conversão. Equipes de serviços de emergência devem tratá-las como potenciais problemas de segurança.

A diferença está na condição do usuário. Alguém relatando um incêndio pode estar assustado, tossindo, afastando-se do perigo ou tentando alertar outros moradores.

A coordenação motora fina e a leitura cuidadosa tornam-se menos confiáveis sob pressão. Um pequeno botão para pular que passa em uma avaliação rotineira de usabilidade pode se tornar funcionalmente inacessível.

O erro relatado por Zhang ilustra essa questão. Ao tentar fechar o anúncio, ela fechou o navegador e precisou reiniciar o processo.

A interface oferecia tecnicamente uma saída do anúncio. Isso não tornou a rota operacionalmente segura.

As regras chinesas de publicidade na internet já reconhecem que um controle nominal de fechamento pode ser inadequado. As regras de publicidade da Administração Estatal de Regulação do Mercado entraram em vigor em 1º de maio de 2023.

O Artigo 10 exige um símbolo de fechamento visível e encerramento com um clique para publicidade pop-up. Ele também proíbe mecanismos de fechamento ocultos, enganosos, difíceis de localizar ou com várias etapas.

A regulamentação aplica expressamente esses requisitos a anúncios exibidos quando um aplicativo é iniciado. No entanto, os relatos disponíveis não documentam o anúncio em detalhes suficientes para determinar se ele violou o Artigo 10.

Não sabemos o tamanho ou a posição do controle para pular. Também não temos uma gravação de tela que estabeleça o tempo, o comportamento repetido ou a sequência exata de interação.

A questão jurídica e a questão de segurança são, portanto, relacionadas, mas diferentes. Um anúncio pode cumprir regras mínimas de fechamento e ainda criar atrito inaceitável durante uma emergência.

A conformidade pergunta se o mecanismo de fechamento atende aos requisitos especificados. A engenharia de segurança pergunta se uma pessoa sob estresse consegue concluir a tarefa de forma confiável em condições adversas.

Esse segundo teste é mais difícil. Ele considera pânico, baixa visibilidade, software desconhecido, mãos trêmulas, mobilidade limitada e dispositivos mais antigos.

Também considera redes degradadas e baixos níveis de bateria. Essas são condições normais para sistemas de emergência, não casos extremos excepcionais.

O incidente em Shenzhen torna esta notícia de tecnologia relevante para desenvolvedores de navegadores, equipes de produto do setor público, anunciantes e operadores de plataformas móveis. Nenhum deles controla sozinho toda a rota.

Essa propriedade fragmentada é precisamente o problema. Cada organização pode alegar que seu componente individual se comportou como projetado, enquanto a jornada combinada ainda falha para o usuário.

O navegador era separado, mas a experiência não

A responsabilidade institucional e a experiência do usuário se separaram no momento em que o Shenzhen 119 transferiu a tarefa para o ambiente de software da moradora.

A resposta de Shenzhen identifica corretamente o limite técnico. Segundo o centro de comando dos bombeiros, o link enviado por mensagem de texto não continha o anúncio de abertura.

O aplicativo de navegador da moradora o forneceu. O departamento também afirmou que o envio não controlava o momento do despacho.

Esses pontos respondem a duas suspeitas imediatas. Não foi relatado que o Shenzhen 119 tenha monetizado a página de emergência, e os bombeiros não estavam esperando atrás de uma tela publicitária.

Ainda assim, usuários não vivenciam serviços digitais por meio de organogramas. Zhang selecionou um link enviado por uma atendente de emergência e encontrou um anúncio antes de chegar ao destino solicitado.

Da perspectiva dela, o anúncio estava dentro do processo de comunicação da ocorrência. Sua propriedade comercial separada não ofereceu proteção prática.

Essa lacuna se assemelha a problemas observados em pagamentos, verificação de identidade, transporte e portais de saúde. Um serviço confiável pode perder o controle quando transfere usuários para software de terceiros.

Links de emergência amplificam esse risco porque chegam inesperadamente. O destinatário não tem tempo para configurar um navegador preferido, desativar anúncios de abertura ou aprender controles desconhecidos.

A própria página do governo pode carregar perfeitamente quando finalmente acessada. Essa métrica de sucesso exclui as etapas que falharam ou foram atrasadas antes do carregamento da página.

Portanto, órgãos públicos devem medir toda a jornada, desde a seleção da mensagem até a confirmação do envio. A disponibilidade do servidor, por si só, não pode mostrar se os moradores chegaram ao serviço sem obstruções.

O mesmo princípio se aplica à acessibilidade digital. Uma página pode cumprir requisitos de acessibilidade, enquanto o aviso do navegador anterior a ela permanece inutilizável para uma pessoa com visão limitada.

As regras da China para sites governamentais fornecem um sinal útil de política pública. A orientação sobre sites do Conselho de Estado proíbe que sites governamentais exibam ou vinculem páginas de publicidade comercial.

Essa orientação não torna automaticamente um anúncio de navegador de terceiros responsabilidade legal do site governamental. Ela mostra que promoção comercial e acesso a serviços públicos devem permanecer separados.

Uma regulamentação de 2024 também afirma que aplicativos governamentais na internet devem apoiar padrões abertos e considerar a compatibilidade entre sistemas de usuários. As agências não devem exigir um navegador ou ambiente de software específico.

Isso cria uma tensão real de design. A ampla compatibilidade favorece links comuns da web, enquanto o comportamento previsível favorece aplicativos controlados ou recursos integrados ao sistema.

Exigir um aplicativo de emergência dedicado introduziria suas próprias falhas. Muitas pessoas não o teriam instalado quando o perigo surgisse.

Um aplicativo nativo também poderia exigir atualização, login ou permissão no pior momento. Transferir a tarefa para um aplicativo não elimina automaticamente o atrito.

O melhor objetivo é uma rota resiliente com várias alternativas. Um morador deve conseguir enviar informações úteis sem depender de uma única sequência de inicialização do navegador.

Rotas possíveis incluem mensagens multimídia padrão, envio baseado em navegador, um canal de emergência do sistema operacional ou uma sessão de vídeo direta iniciada pelo despacho.

Cada rota envolve preocupações com privacidade, capacidade e autenticação. No entanto, a redundância impede que uma interface comercial se transforme em um único ponto de falha.

O serviço também deve preservar a primazia da ligação telefônica. Mídias complementares nunca devem se tornar uma condição implícita para o envio de equipes.

Shenzhen afirma que essa salvaguarda já existia neste caso. O incidente demonstra por que as agências devem comunicá-la com clareza aos solicitantes.

Um atendente poderia dizer que as equipes já estão a caminho antes de solicitar um vídeo. Essa breve garantia reduz a pressão e desestimula os solicitantes a permanecerem perto do perigo para obter imagens melhores.

A página do link deve repetir a mesma mensagem. Ela deve orientar os usuários a priorizar a evacuação e evitar filmar quando isso gerar riscos.

Regras sobre anúncios tratam do fechamento, não do contexto de emergência

Os controles publicitários atuais se concentram no comportamento da interface, enquanto o caso de Shenzhen exige uma supressão sensível ao contexto.

Os reguladores chineses passaram anos combatendo anúncios de abertura que resistem ao fechamento ou provocam redirecionamentos não intencionais. A questão já estava bem estabelecida antes da reportagem sobre o incêndio em Shenzhen.

Em 2021, o Ministério da Indústria e Tecnologia da Informação examinou 550.000 aplicativos em um trimestre. Identificou publicamente 601 aplicativos com problemas e removeu 163 que se recusaram a adotar medidas corretivas.

O ministério afirmou que os saltos enganosos entre telas de abertura em grandes empresas de internet haviam caído para uma taxa de detecção de um por cento. Esses dados de fiscalização mostraram melhora, não eliminação.

O órgão regulador também exigiu controles de fechamento claros e eficazes. Imagens ou vídeos em tela cheia não devem funcionar como links enganosos que abrangem toda a página.

A Administração do Ciberespaço da China acrescentou outra camada em 2022. Suas disposições sobre pop-ups exigem rótulos publicitários, marcas de fechamento visíveis e dispensa com um clique.

Essas regras abordam danos reconhecíveis. Elas visam controles confusos, visualização forçada, links disfarçados e interferência repetida.

Elas não estabelecem um método técnico abrangente para detectar destinos de serviços de emergência. Um navegador pode seguir todas as regras de fechamento sem saber que a próxima página se refere a um incêndio ativo.

O comentário de Shenzhen propôs um “canal verde” que suprimiria anúncios em links de emergência e médicos. O objetivo é sensato, mas a implementação exige limites cuidadosos.

Navegadores poderiam manter listas verificadas de domínios governamentais de emergência. Um anúncio de abertura seria suprimido sempre que um link selecionado apontasse para um destino listado.

Esse método é relativamente simples, mas as listas de domínios exigem manutenção. Agências locais podem usar vários domínios, serviços em nuvem, redirecionamentos ou links curtos.

Atacantes também poderiam imitar domínios de emergência para contornar os controles do navegador. A verificação deve impedir que criminosos obtenham tratamento confiável para páginas fraudulentas.

Uma segunda abordagem usaria links assinados. O serviço de emergência poderia anexar um token criptográfico que comprovasse que o destino pertence a um fluxo de segurança verificado.

Navegadores e sistemas operacionais poderiam reconhecer esse token e entrar em um modo sem distrações. Essa abordagem oferece autenticação mais forte, mas exige coordenação entre agências e fornecedores de software.

Uma terceira abordagem classificaria links com base no texto ou no conteúdo do destino. A classificação automatizada poderia sinalizar mensagens contendo números de emergência ou terminologia de resgate.

Esse método corre o risco de não detectar emergências e de gerar falsos positivos. Também poderia expor informações sensíveis de mensagens ou navegação a inspeções desnecessárias.

A abordagem mais segura no curto prazo combina domínios verificados, validação de redirecionamentos e limites de tempo rigorosos. Ela deve evitar a leitura de conteúdo privado além do necessário para o roteamento.

As plataformas já tomam decisões contextuais sobre pagamentos, sites maliciosos, links de aplicativos e fluxos de identidade. Criar uma categoria para links de emergência é tecnicamente plausível.

O maior obstáculo é a governança. Alguém precisa definir os serviços elegíveis, emitir credenciais, lidar com revogações, auditar abusos e coordenar os relatórios de incidentes.

Os fornecedores de navegadores também precisam de um incentivo comercial ou de uma exigência regulatória. Um anúncio de abertura gera valor justamente porque aparece antes da tarefa pretendida pelo usuário.

As isenções reduzem as impressões. Sem uma regra vinculante, links de emergência podem continuar raros demais para ganhar prioridade frente à receita publicitária mensurável.

Esse é o principal dilema. Uma regra ampla de supressão pode ser abusada, enquanto uma regra restrita pode deixar de fora serviços locais legítimos.

O caso de Shenzhen não prova qual arquitetura deveria prevalecer. Ele prova que depender de um usuário sob estresse para encontrar “pular” é um padrão inadequado.

O vídeo pode melhorar o atendimento sem se tornar um novo risco

O vídeo de emergência é valioso quando acrescenta informações após o envio das equipes, não quando muda a primeira obrigação do solicitante de escapar para documentar.

As imagens podem resolver incertezas que as descrições por voz deixam em aberto. Os solicitantes podem avaliar incorretamente a cor da fumaça, a localização do andar, a propagação das chamas ou o tipo de estrutura envolvida.

Um atendente pode usar informações visuais para fazer perguntas melhores. A equipe de comando pode repassar detalhes relevantes às equipes que já estão a caminho do local.

Os sistemas chineses de emergência testam essas capacidades há anos. Em 2020, Guiyang introduziu um serviço de comunicação de incêndios via WeChat que aceitava localizações e imagens.

A autoridade local de combate a incêndios afirmou que o sistema ajudava a lidar com localizações imprecisas e descrições verbais pouco claras. Seu exemplo de envio de vídeo também mostrou por que provas visuais podem melhorar a avaliação de recursos.

Mais tarde, Guangdong introduziu uma conexão de vídeo com suporte da Huawei para chamadas policiais ao 110. O sistema podia compartilhar informações de localização e foi descrito como adaptável aos serviços 119 e 120.

Esses projetos refletem uma mudança mais ampla das comunicações de emergência apenas por voz para dados móveis mais ricos. Essa mudança pode melhorar a consciência situacional, mas também amplia a superfície de ataque do sistema.

Cada link adicional cria novas dependências. Elas incluem navegadores, permissões de câmera, compressão de mídia, servidores de upload, armazenamento de conteúdo e redes móveis.

O vídeo também introduz preocupações de privacidade. Uma gravação da cena de um incêndio pode capturar pessoas feridas, interiores de apartamentos, placas de veículos ou rostos.

As agências precisam de regras claras de retenção e acesso limitado. Elas devem coletar apenas material relacionado à avaliação e à investigação da emergência.

A autenticação também é importante. Um endpoint público de upload poderia atrair denúncias falsas, material gráfico, spam ou sobrecarga coordenada.

O sistema deve associar a mídia a um incidente ativo sem obrigar o solicitante a passar por um login demorado. Esse equilíbrio exige engenharia cuidadosa.

A largura de banda representa outra limitação. Vídeos em alta resolução podem falhar em redes congestionadas, especialmente quando muitas pessoas relatam o mesmo incidente.

Um fluxo de upload deve reduzir automaticamente o tamanho do arquivo. Ele deve preservar detalhes úteis, ao mesmo tempo que confirma o progresso e permite retomar uma transferência que falhou.

A interface também deve distinguir vídeo ao vivo de upload de gravações. Cada um impõe exigências diferentes quanto à qualidade da rede, à atenção do atendente e ao tratamento de evidências.

Mais importante ainda, a solicitação não deve incentivar comportamentos arriscados. Os solicitantes não devem se aproximar das chamas, permanecer em meio à fumaça ou atrasar a evacuação para melhorar as imagens.

Um fluxo de trabalho bem projetado deve informar que as equipes já foram enviadas, quando isso for verdade. Ele deve dizer ao usuário para fazer o upload apenas de um local seguro.

O sistema também pode aceitar imagens já existentes em vez de solicitar uma nova gravação. Isso reduz a pressão para documentar um risco em evolução.

Desenvolvedores de navegadores e sistemas operacionais compartilham a responsabilidade nesse ponto. Um link de emergência deve receber a mesma seriedade de design que um alerta de fraude ou uma transição segura para pagamento.

A comparação útil não é entre publicidade e uma página comum. É entre receita publicitária e uma ação verificada e sensível ao tempo de segurança pública.

Esse enquadramento muda as taxas de falha aceitáveis. Uma interrupção rara ainda pode merecer correção quando a tarefa afetada envolve incêndio, atendimento médico ou perigo pessoal.

Também muda os testes. As equipes de produto devem avaliar os caminhos de emergência com exercícios cronometrados e orientados ao estresse, em vez de se limitarem a interações tranquilas de laboratório.

Usuários mais velhos, pessoas com deficiência e usuários de dispositivos desconhecidos devem participar. Seus resultados frequentemente revelam falhas ocultas para testadores especialistas.

O incidente continua sendo uma evidência limitada, baseada em um único usuário relatado. Ele deve motivar verificação e revisão de design, não alegações sem respaldo sobre todos os navegadores ou links de emergência.

Três sinais mostrarão se o sistema realmente muda

A resposta significativa aparecerá no comportamento dos produtos e em salvaguardas verificadas, não em mais uma promessa genérica de melhorar a experiência do usuário.

O primeiro sinal é se Shenzhen publicará uma análise técnica da jornada completa de upload. Essa análise deve identificar o comportamento dos redirecionamentos, os navegadores compatíveis e os pontos de falha antes do carregamento da página de emergência.

Ela também deve confirmar se o link usa um domínio estável, controlado pelo governo. Caso intermediários ou URLs encurtadas sejam usados, a análise deve explicar por que eles são necessários.

Uma análise pública reforçaria o argumento de que as agências são responsáveis pela experiência de ponta a ponta, mesmo quando não controlam todas as camadas de software. O silêncio deixaria a mesma dependência sem análise.

O segundo sinal é se fornecedores de navegadores e celulares introduzirão a supressão verificada de links de emergência. O recurso deve ignorar anúncios de abertura sem exigir que os usuários alterem configurações durante uma crise.

Uma implementação confiável definiria autenticação, serviços elegíveis, controles contra abusos e limites de privacidade. Uma vaga promessa de “otimização” forneceria pouca evidência de melhoria.

Esse sinal importa porque o navegador supostamente criou a obstrução. Um redesenho apenas pela agência não pode controlar integralmente um aplicativo que insere conteúdo antes de carregar o destino.

O terceiro sinal é se os reguladores testarão cenários de emergência durante a fiscalização da publicidade. As regras existentes já exigem anúncios reconhecíveis e fechamento eficaz com um clique.

Os reguladores poderiam acrescentar inspeções baseadas em cenários envolvendo links governamentais, médicos, de transporte e de emergência. Esses testes revelariam se controles formalmente compatíveis continuam utilizáveis sob pressão de tempo.

Uma isenção de emergência direcionada fortaleceria o argumento em favor de uma governança publicitária sensível ao contexto. A dependência contínua de regras gerais sobre botões de fechamento a enfraqueceria.

Diversas incertezas devem permanecer visíveis enquanto esses sinais se desenvolvem. O navegador não foi identificado publicamente, e seu operador não apresentou uma explicação técnica.

O formato exato do anúncio não foi documentado de forma independente nas reportagens citadas. Nenhum regulador determinou publicamente que a exibição violou a legislação publicitária.

Também não há evidências de que o envio das equipes tenha sido atrasado. O corpo de bombeiros de Shenzhen afirma que a resposta começou imediatamente, e as reportagens disponíveis não contradizem essa alegação.

Esses limites impedem que a história se transforme na alegação de que um anúncio impediu a atuação dos bombeiros. Com base no registro verificado, isso não ocorreu.

A conclusão mais precisa diz respeito ao design do sistema. Um anúncio interrompeu um fluxo solicitado por um atendente, que deveria transmitir informações úteis da cena do incêndio.

Essa interrupção revelou um limite em que software comercial pode degradar um serviço público sem aparecer na própria infraestrutura da agência pública.

Para leitores que acompanham notícias de tecnologia, este é um pequeno incidente com uma lição duradoura. O governo digital não pode avaliar apenas as páginas e os servidores que opera diretamente.

As equipes devem mapear cada transferência, incluindo aplicativos de mensagens, sistemas operacionais, navegadores, permissões, redirecionamentos e confirmações de upload. Em seguida, devem testar essas transferências sob estresse realista.

As empresas de navegadores devem fornecer um processo documentado para que serviços de emergência verificados possam suprimir interrupções comerciais. Órgãos públicos devem exigir essa capacidade e manter canais alternativos de denúncia.

Os reguladores devem examinar se o “fechamento com um clique” continua sendo algo significativo quando o usuário está denunciando um incêndio. A disponibilidade legal e a usabilidade prática nem sempre são a mesma coisa.

Na próxima vez que um link de emergência chegar a um telefone, o comportamento desejado é simples. O serviço deve abrir imediatamente, explicar que a ajuda está a caminho e manter o usuário focado na segurança.

Fique atento a essas três mudanças concretas: uma revisão da rota de Shenzhen, isenções verificadas para navegadores e testes regulatórios voltados a emergências. Qualquer medida inferior a isso deixa a falha subjacente intacta.

 
 

Comece grátis

Um assistente de IA local-first com gestão de conhecimento pessoal

Para oferecer uma experiência de IA melhor,

atualmente, o remio é compatível apenas com Windows 10+ (x64) e M-Chip Macs.

Seu parceiro de IA no trabalho
Faça mais com o remio

Planeje. Crie. Entregue.
Tudo em um só lugar.

bottom of page