Quando eu leio “inovação aberta” eu já desconto o hype. Mas o caso da Dexco com a Subiter me chamou atenção porque não é só P&D bonito: é economia mensurável no fluxo de caixa. Segundo o Abril.com.br, o Open Dexco desde 2022 já capturou mais de R$ 10 milhões em economia, e um dos protagonistas foi uma inspeção instantânea por luz que substituiu testes químicos demorados e destrutivos.
Na prática, é o tipo de projeto que dev adora porque tem lógica, integração e impacto direto. E também é o tipo de iniciativa onde dá para errar feio se você não desenhar bem o pipeline de dados, os critérios de qualidade e como o time de chão de fábrica vai operar o sistema no mundo real.
O que a Dexco está fazendo com inovação aberta (e por que isso funciona)
Segundo o Abril.com.br, a Dexco colocou a inovação aberta para trabalhar no “caixa”. Isso muda a conversa: deixa de ser “temos uma startup incrível” e vira “temos um problema com custo e desperdício e precisamos reduzir isso rápido”.
O Open Dexco, desde 2022, é basicamente um mecanismo de captura de soluções externas, com foco em retorno. No caso citado, a parceria com a Subiter criou tecnologia para detectar porosidade em chapas de MDP usando luz (inspeção não destrutiva e em tempo muito menor que métodos químicos).
Esse detalhe é crucial para quem programa e projeta sistemas industriais: quando o gargalo é tempo de teste e destruição de amostra, qualquer redução imediata vira ganho financeiro quase “automático”. É diferente de otimizar algo que só acontece no “depois”, como relatórios ou dashboards sem ação.
O problema técnico por trás do “teste químico com tolueno”
Quando a fonte menciona que os testes químicos com tolueno levavam até 24 horas, eu leio três implicações técnicas:
- Tempo de ciclo alto: o processo de decisão fica atrasado e você descobre defeitos tarde demais.
- Acoplamento físico e consumo: reagentes têm custo, logística, validade e exigências de segurança.
- Teste destrutivo: amostras saem do processo. Isso aumenta desperdício e reduz rendimento efetivo.
A tecnologia por luz substitui parte disso por verificação instantânea. O retorno citado (R$ 5 milhões em oito meses na unidade de Taquari/RS) aponta que reduzir devoluções, perdas e desperdícios foi relevante o suficiente para acelerar o ROI.
Como uma inspeção por luz vira economia de verdade (não só “qualidade”)
Vamos traduzir o caso em uma cadeia de valor que faz sentido para engenharia de software:
- Detecção mais rápida → decisões antes do lote seguir.
- Não destrutiva → menos perda de material em testes.
- Menos devolução → reduz retrabalho, logística reversa e penalidades comerciais.
- Menos desperdício → melhora rendimento e planejamento de produção.
Quando você programa um sistema desses, a pergunta não é “o modelo acerta?” apenas. A pergunta é: o que acontece no sistema produtivo quando ele erra? Um classificador com taxa de erro baixa mas sem estratégia de fallback pode gerar mais prejuízo que benefício.
Por que inspeção óptica é diferente de inspeção “digital” tradicional
Muitos devs tentam encaixar visão computacional como se fosse um app web comum. No chão de fábrica, a realidade é outra: variação de iluminação, poeira, reflectância, variação de lote, calibração de câmera, ruído e geometria. Se você trata isso como “um dataset e pronto”, você vai apanhar na operação.
O jeito correto é enxergar como sistema cyber-físico: há sensor, pipeline de pré-processamento, validação, e então decisão que muda o fluxo.
Arquitetura prática: do sensor ao “veredito” com rastreabilidade
O Abril.com.br cita tecnologia de inspeção por luz e economia associada. Para levar isso adiante (como a Dexco e Subiter já estudam levar para outras unidades), você precisa de uma arquitetura que suporte:
- Calibração e manutenção (o que garante consistência ao longo do tempo)
- Rastreabilidade (qual câmera, qual lote, qual versão do modelo)
- Baixo downtime (offline/online, filas, retry)
- Auditoria (por que aceitou/reprovou)
- Integração com MES/ERP (para ação real no processo)
Comparando alternativas: por que “software + luz” costuma ganhar
Em geral, as alternativas para inspeção em manufatura entram em três buckets:
- Ensaios laboratoriais/químicos: alto custo, tempo e destruição. Bom para validação, ruim para decisão rápida.
- Inspeção humana: custo e variação humana; funciona como triagem, mas escala mal.
- Visão computacional/inspeção por sensor: investe uma vez, depois automatiza. Exige engenharia de robustez e operação.
O caso da Dexco encaixa no bucket 3. O salto de economia sugere que a solução ficou estável o suficiente para ser usada na rotina e que a integração evitou “um sistema que só grava imagens”.
Na prática: como eu desenharia um pipeline para esse tipo de inspeção
Abaixo está um passo a passo que eu aplico quando tento transformar inspeção visual em um sistema “de chão de fábrica”:
- Defina as classes e a ação: “porosidade detectada” implica o quê? Reprovar, reprocessar, ajustar parâmetros?
- Crie um protocolo de amostragem: quais peças entram como treino? Como você garante que o dataset represente a operação real?
- Implemente pré-processamento robusto: normalização de iluminação, controle de ROI (região de interesse) e filtros para ruído.
- Valide em lotes, não em imagens soltas: métricas por peça são ótimas, mas o impacto é por lote.
- Controle de versão: versão do modelo, parâmetros e calibração ficam registrados junto do resultado.
- Fallback explícito: se confiança baixa, ou se condições fora do esperado, o sistema encaminha para “inspeção assistida” ou “amostra para laboratório”.
- Integração com fluxo: o veredito precisa chegar no lugar certo (MES/planilha/rota de produção) com latência aceitável.
Trecho de código funcional: inferência com threshold e rastreabilidade
Exemplo simples (Python) de como eu registraria um resultado com versão de modelo, confiança e ação. É o tipo de coisa que facilita auditoria e debugging quando algo “só falha na unidade X”.
import json
import time
from dataclasses import dataclass
from typing import Dict, Any
@dataclass
class InferenceResult:
label: str
confidence: float
decision: str
model_version: str
sensor_id: str
ts_unix_ms: int
meta: Dict[str, Any]
def decide(label: str, confidence: float,
threshold_reject: float = 0.75,
threshold_review: float = 0.50) -> str:
# 1) Alta confiança: reprova/aceita
if confidence >= threshold_reject:
return "REPROVAR" if label == "POROSIDADE" else "ACEITAR"
# 2) Confiança intermediária: revisão humana ou teste rápido
if confidence >= threshold_review:
return "REVISAR"
# 3) Baixa confiança: fallback (evita decisões erradas)
return "FALLBACK_LAB"
def run_inference(image_bytes: bytes,
model, model_version: str,
sensor_id: str) -> InferenceResult:
# Supõe que 'model.predict' retorne (label, confidence)
label, conf = model.predict(image_bytes)
decision = decide(label, conf)
return InferenceResult(
label=label,
confidence=float(conf),
decision=decision,
model_version=model_version,
sensor_id=sensor_id,
ts_unix_ms=int(time.time() * 1000),
meta={"input_size": len(image_bytes)}
)
def serialize_to_event(result: InferenceResult) -> str:
payload = {
"label": result.label,
"confidence": result.confidence,
"decision": result.decision,
"model_version": result.model_version,
"sensor_id": result.sensor_id,
"ts_unix_ms": result.ts_unix_ms,
"meta": result.meta
}
return json.dumps(payload, ensure_ascii=False)
# Exemplo de uso:
# event = serialize_to_event(run_inference(img, model, "subiter-v3", "CAM-TAQ-01"))
# enviar 'event' para o seu barramento/fila (Kafka, PubSub etc.)
O “porquê” aqui é simples: sem rastreabilidade (versão, sensor, timestamp) você vira refém de “achismo” quando muda iluminação, câmera ou parâmetros. O custo de perder isso em indústria é alto, porque você não consegue reproduzir a falha.
Erros comuns (os que eu já vi estourarem em produção)
Se você vai seguir esse caminho com IA industrial, tome cuidado com estes pontos. Eles aparecem muito quando times “de software” entregam algo para operação.
1) Treinar com dataset que não reflete a fábrica
Resultado: a acurácia em validação fica boa, mas a operação real derruba. Mistura de iluminação e variação de lotes costuma ser o vilão.
2) Não tratar fallback
Um modelo com 90% de acerto e sem mecanismo de incerteza pode gerar decisões erradas em massa. Em manufatura, o “custo do erro” é assimétrico.
3) Medir sucesso só por métricas de ML
O que importa é: redução de retrabalho, devoluções, perda de material, tempo de ciclo e estabilidade. No caso da Dexco, o que rankeia é a economia (R$ 5 milhões em 8 meses na unidade citada).
4) Falta de versionamento e auditoria
Quando a equipe muda o modelo “sem avisar”, a auditoria vira pesadelo. Você perde capacidade de explicar por que um lote foi reprovado ou aceito.
5) Integrar tarde com o fluxo do chão de fábrica
Se a decisão fica num dashboard bonito, mas não muda rota de produção, a economia não acontece. Sistemas com impacto real são aqueles conectados ao processo.
Por que o ciclo de 2026 da Dexco muda o foco (e o que isso sugere para devs)
Segundo o Abril.com.br, no ciclo de 2026 a Dexco apertou o foco: desafios escolhidos pela diretoria com meta de impacto rápido no fluxo de caixa. Isso inclui projetos de IA industrial, operação remota florestal, eficiência hídrica e auditoria automatizada de fretes.
Do ponto de vista de quem programa, isso indica um padrão de “industrialização” de IA:
- Menos experimentos sem dono e sem métricas.
- Mais engenharia para operacionalizar (monitoramento, confiabilidade e integrações).
- Prioridade para casos com feedback rápido e ROI mensurável.
Ou seja: não é só desenvolver. É transformar em sistema. Isso envolve arquitetura, governança e mudança de rotina.
FAQ
Como uma inspeção por luz evita desperdício na prática?
Ela detecta porosidade sem destruir a amostra e em tempo muito menor do que testes químicos. Com isso, decisões acontecem antes do lote seguir, reduzindo devoluções, retrabalho e perda de material.
Qual é a diferença entre “IA que detecta” e “sistema que gera economia”?
IA que detecta só responde à classificação. O sistema que gera economia também decide a ação, integra com o fluxo (MES/rotas), aplica fallback e mede métricas de negócio (perdas, devoluções, tempo de ciclo).
Por que o versionamento do modelo é tão importante?
Porque em indústria você precisa auditar decisões. Quando um lote muda de resultado após troca de câmera, iluminação ou modelo, sem versionamento você não consegue reproduzir o cenário e corrigir rápido.
O que costuma falhar quando expandem para outras unidades?
Variações de ambiente (iluminação, posicionamento do sensor), diferenças de matéria-prima e ausência de calibração/configuração por unidade. Sem um framework de adaptação, o desempenho cai.
Como eu escolho threshold (limiar) de reprovação/revisão?
Eu começo pelo custo do erro e pela análise de casos reais: qual taxa de falso positivo e falso negativo é aceitável? Depois valido por lote e implemento três modos (aceitar, revisar, fallback) para controlar risco.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.