# Como detectar anomalias em dados de sensores IoT usando IA

> As quatro formas que uma anomalia de sensor assume, picos, desvio, silêncio e falhas correlacionadas, por que limiares fixos deixam três delas passar, e como montar a detecção na TagoIO com linhas de base estatísticas, TagoAI, Analysis e Actions.

![Como detectar anomalias em dados de sensores IoT usando IA](https://tago.io/og/pt-br/blog/detect-iot-anomalies-with-ai.png)

Toda equipe que monitora sensores começa do mesmo jeito: escolhe um limite e alerta quando uma leitura o cruza. Temperatura acima de 8 graus, vibração acima de 4 mm/s, corrente acima de 20 amperes. Para limites físicos rígidos, isso está exatamente certo.

Mas as falhas que custam dinheiro de verdade quase nunca se anunciam com uma leitura fora de faixa. Elas se escondem dentro de leituras que, uma a uma, parecem normais. Um compressor desvia dois graus ao longo de três semanas. Um medidor de vazão fica em silêncio às 2 da manhã e ninguém percebe até o turno da manhã. Uma anomalia não é "um número grande". É uma leitura, ou a ausência de leituras, que o padrão normal não teria previsto.

![Uma anomalia é uma leitura que o padrão esperado não previu.](https://tago.io/images/blog/detect-iot-anomalies-with-ai/anomaly-detection-band.svg)

## As quatro formas de anomalia em dados de sensores

Na prática, anomalias de sensor aparecem em quatro formas, e só a primeira é visível para um limite fixo.

**Picos** são a mais óbvia. Um valor salta bem fora da faixa recente e volta. Alguns picos são eventos reais, muitos são ruído elétrico ou falha momentânea do sensor, e distinguir um do outro geralmente exige olhar mais de uma leitura.

**Desvio** é mais lento e mais caro. Um sensor, ou o processo por trás dele, se afasta gradualmente da linha de base sem sair dos limites de alerta em nenhum momento. Perda de calibração, filtros entupindo e vazamento de refrigerante se apresentam como desvio. Quando um limiar fixo finalmente dispara, o problema já tem semanas.

**Silêncio** é a anomalia que a maioria dos monitoramentos esquece. Um dispositivo que para de reportar não produz dado nenhum para avaliar, então regras baseadas em valor nunca disparam. Dado ausente também é dado.

**Falhas correlacionadas** atravessam dispositivos. Um gateway travou e trinta sensores silenciaram juntos, ou todas as unidades de uma mesma fase elétrica dispararam no mesmo minuto. Nenhuma regra por dispositivo enxerga isso, porque o padrão só existe no conjunto da frota.

![As quatro formas de anomalia: um pico que sai da faixa e volta, o desvio se afastando da linha de base, o silêncio sem dado nenhum e a falha correlacionada em muitos dispositivos no mesmo momento](https://tago.io/images/blog/detect-iot-anomalies-with-ai/anomaly-four-patterns.svg)

Detectar também é um trabalho diferente de prever. Se o que você quer é um aviso antes de um valor cruzar um limite, e não um sinal depois de ele se comportar de forma estranha, isso é previsão, e a [diferença entre as duas coisas](https://tago.io/blog/anomaly-detection-vs-forecasting-iot) define qual delas você deve construir.

## Limiares e estatística: quando os métodos clássicos bastam

Não pule as ferramentas clássicas, porque para uma boa parte das anomalias elas são a resposta correta, não um remendo.

Um limiar estático é barato, transparente e exatamente certo quando o limite é físico ou contratual. Uma geladeira de vacinas precisa ficar abaixo de 8 graus, e ninguém precisa de machine learning para garantir isso. As [Actions](https://docs.tago.io/docs/tagoio/actions/) da TagoIO cuidam disso direto: defina a condição, defina a resposta, pronto.

Uma linha de base estatística cobre o nível seguinte. Calcule média e desvio padrão móveis por sensor, sinalize leituras além de três desvios padrão, e você pega picos e desvios que limites fixos deixam passar, porque a faixa se move junto com os dados. Segmente essa linha de base por hora do dia ou modo de operação e a precisão melhora de novo: temperatura normal às 2 da manhã pode ser anormal às 2 da tarde. O silêncio precisa de outra regra, um tempo limite: se um dispositivo não reportou dentro do dobro do intervalo habitual dele, isso é uma anomalia independentemente dos valores.

É estatística sem glamour, e ela supera um modelo de IA ingênuo na maioria dos fluxos de sensores porque codifica o que você de fato sabe sobre o processo.

Onde os métodos clássicos se esgotam é justamente onde o trabalho fica tedioso: escolher a janela certa por variável, tratar sazonalidade, comparar comportamento entre centenas de dispositivos, correlacionar várias variáveis ao mesmo tempo. Nada disso é conceitualmente difícil. Tudo isso são horas de código e decisões de julgamento por frota, e é por isso que a maioria das equipes para nos limiares e convive com os pontos cegos. Essa lacuna é a que a IA realmente preenche.

## O que a IA acrescenta, honestamente

"Detecção de anomalias com IA" é vendida como um modelo que magicamente sabe que algo está errado. O enquadramento mais útil: a IA elimina o trabalho braçal entre saber como é um bom pipeline de detecção e ter um rodando contra a sua própria frota.

Modelos de machine learning treinados ganham seu lugar na ponta mais alta, para padrões multivariados, sazonalidade forte e frotas grandes demais para ajuste sensor a sensor. Antes desse ponto, um assistente de IA que consegue ver seus dispositivos e dados reais derruba o custo de construir o próprio pipeline clássico, e é aí que a maioria das equipes tem o retorno mais rápido.

## Explorando a sua frota com o TagoAI

O TagoAI é o assistente de IA embutido no Admin da TagoIO, atrás do ícone de estrela. Ele é ancorado na documentação oficial e na sua própria conta: consegue inspecionar seus Devices, Dashboards, Actions e scripts de Analysis, e é sensível ao contexto, então abri-lo de uma página de Analysis ou Dashboard significa que ele já sabe o que está olhando.

O que importa para o trabalho com anomalias é que ele executa operações de análise de dados entre os seus dispositivos. Você pode perguntar, em linguagem natural, quais sensores reportaram valores a mais de três desvios padrão da própria média de duas semanas, quais dispositivos têm lacunas maiores que uma hora no último dia, ou se as unidades atrás do gateway 7 silenciaram no mesmo instante. Isso é detecção exploratória de anomalias sem código, e é assim que você aprende como é o normal da sua frota antes de automatizar qualquer coisa.

Ele também se comporta como um assistente com acesso à conta deve se comportar. Começa somente leitura, você eleva as permissões por sessão, ele nunca muda nada em silêncio e tudo o que faz fica registrado no Audit Log. O [passo a passo detalhado](https://tago.io/blog/use-ai-assistant-query-live-iot-device-data) cobre a troca de modos e os hábitos que vale criar, e as [escolhas de provedor e privacidade](https://tago.io/blog/query-iot-data-natural-language-ai) estão apresentadas separadamente.

## Gerando a lógica de detecção como código de Analysis

A exploração encontra anomalias uma vez. A detecção em produção tem de rodar a cada poucos minutos, sem ninguém olhando. Na TagoIO, isso é uma [Analysis](https://docs.tago.io/docs/tagoio/analysis/): um script que roda em intervalo definido, lê os dados recentes, aplica a sua lógica de detecção e grava de volta um sinal de anomalia como variável.

Em vez de escrever esse script de uma página em branco, peça ao TagoAI para gerá-lo. Como ele consegue inspecionar seus dispositivos e formatos de dados reais, o código que produz trata dos seus nomes de variável, unidades e intervalos de envio de verdade, e não de um exemplo genérico. Descreva a lógica que você fechou durante a exploração: linha de base móvel por sensor, três desvios padrão, segmentada por hora, mais uma checagem de silêncio no dobro do intervalo de envio. Revise o código, ajuste e publique. Quando um script der problema depois, o TagoAI o depura com o mesmo contexto de conta.

O resultado é uma lógica de detecção que você consegue ler, versionar e confiar, produzida em minutos em vez de dias. A IA fez o trabalho braçal; a lógica continua sua e continua auditável. Percorremos esse fluxo ao vivo, da descrição em linguagem natural até uma Analysis rodando, no webinar [AI Meets IoT: A Practical Experience with TagoAI](https://tago.io/videos/ai-meets-iot-a-practical-experience-with-tagoai).

## Alertando com Actions

Detecção e alerta devem ficar separados. A Analysis grava um sinal de anomalia; uma [Action](https://docs.tago.io/docs/tagoio/actions/) da TagoIO observa essa variável e cuida da resposta, seja e-mail, SMS, notificação push ou um webhook para o seu sistema de tickets.

Manter os dois separados permite apertar a lógica de detecção sem tocar no roteamento de alertas, e permite encaminhar a mesma variável de anomalia para equipes diferentes conforme a severidade.

## Investigando o que foi sinalizado

Uma linha de base diz que a Unidade 4 estourou às 3h20. Ela não diz por quê, nem se aquilo faz parte de um padrão, nem o que fazer. Essa investigação, correlacionar o desvio com outras variáveis, checar se a mesma unidade deu problema na semana passada e rascunhar a correção, é exatamente o que um assistente de IA faz bem quando alcança seus dados reais.

Se o seu assistente vive fora da TagoIO, o [TagoIO MCP server](https://docs.tago.io/docs/tagoio/tago-ai/tagoio-mcp-ai-powered-iot-data-integration) lhe dá o mesmo alcance: puxar as leituras ao redor, checar o histórico do dispositivo e propor uma Action mais rígida. A detecção continua estatística e auditável, enquanto a IA faz a correlação tediosa e o primeiro rascunho da resposta. O quadro mais amplo está em [o que o MCP significa para IoT](https://tago.io/blog/what-is-model-context-protocol-mcp-for-iot).

## Uma ordem de construção que sobrevive à produção

Comece com Actions nos seus limites rígidos de verdade, hoje, sem IA nenhuma. Depois use o TagoAI para explorar como a sua frota se comporta de fato e descobrir quais variáveis desviam, dão pico ou silenciam. Em seguida, peça a ele que gere a Analysis que codifica o que você aprendeu, e ligue uma Action ao sinal de anomalia. Acrescente checagens no nível da frota para falhas correlacionadas quando a detecção por dispositivo estiver estável. Recorra a modelos de machine learning treinados só quando o pipeline estatístico comprovadamente deixar passar padrões que importam para você.

A armadilha a evitar é começar pelo fim. Uma IA investigando anomalias que você ainda não aprendeu a detectar de forma confiável é um chute confiante sobre uma base instável. Detecção primeiro, explicação depois.

## O resumo

Anomalias em dados de sensores chegam como picos, desvio, silêncio e falhas correlacionadas, e três das quatro são invisíveis para limiares fixos. A estatística clássica as detecta bem, mas custa tempo real de engenharia por frota, e é esse tempo que a IA elimina: TagoAI para explorar o comportamento entre dispositivos, código de Analysis gerado para a detecção em produção, Actions para o alerta e um assistente para investigar o que foi sinalizado.

Construa nessa ordem e você tem um sistema preciso, depurável e realmente útil, em vez de uma demonstração impressionante em que ninguém confia em produção. Veja [Analysis](https://docs.tago.io/docs/tagoio/analysis/) e [Actions](https://docs.tago.io/docs/tagoio/actions/) na documentação, ou [comece grátis na TagoIO](https://admin.tago.io) e sinalize sua primeira anomalia esta semana.

[llms.txt](https://tago.io/llms.txt)