RPA & AutomaçãoIntegraçõesLeitura 5 min

O Portal Público Mudou de Layout (de Novo): Quem Paga a Manutenção do Robô

Fonte pública muda layout, adiciona captcha e migra de sistema sem avisar. A diferença entre comprar ferramenta de RPA e contratar coleta como serviço, e o que perguntar ao fornecedor.

Jonas HamerskiData Engineer | RPA/Web Scraping | Backend Python8 de julho de 20265 min

Existe uma diferença que só aparece no sexto mês de projeto: quem assume o custo quando o portal público muda.

Fonte pública troca de layout, adiciona captcha ou migra de sistema sem avisar ninguém. Não existe changelog, não existe aviso prévio, não existe SLA do órgão com você. Simplesmente na terça-feira o robô para de funcionar.

A pergunta que decide o modelo de contratação é: de quem é essa conta?


Ferramenta vs. Serviço: a linha que separa os dois

Se você comprou ferramenta

Você recebeu uma plataforma de automação e a responsabilidade de operar. Quando o portal muda, o robô é seu. Alguém do seu time, ou um consultor que você paga por hora, precisa entender o que mudou, ajustar o seletor, testar e subir de novo.

O custo real não é a licença. É a fila de manutenção que nunca esvazia, porque você não coleta de uma fonte só, e as fontes não combinam entre si de mudar no mesmo dia.

Se você contratou serviço

Você contratou a entrega do dado. O robô é do fornecedor, a manutenção é do fornecedor e a adaptação quando a fonte muda não vira chamado seu. Nenhum código de automação fica com o seu time para sustentar.

A consequência contratual é direta: você paga pela entrega, não pelo conserto.


Os Três Modos de Quebra e o Que Cada Um Exige

1. Mudança de layout

O caso mais comum. O campo mudou de lugar, a tabela virou lista, o rótulo mudou de nome.

O requisito técnico aqui é contraintuitivo: a extração precisa falhar alto. Se o robô não encontra o campo, isso tem que virar erro explícito e alerta, não campo vazio. Campo vazio por mudança de layout é o pior defeito possível, porque se parece com um dado legítimo e atravessa todo o processo sem levantar suspeita.

2. Captcha novo ou mais agressivo

O portal passa a exigir verificação onde antes não exigia, ou aperta o critério.

A regra de ouro não muda: falha de captcha volta para a fila de reprocessamento e nunca vira "nada consta". Um falso negativo silencioso é pior que uma coleta que demora. O primeiro produz decisão errada com aparência de certeza; o segundo produz atraso visível.

3. Migração de sistema

O órgão troca a plataforma inteira. URL nova, fluxo novo, às vezes autenticação nova.

Esse caso não se resolve com ajuste: é reconstrução da coleta daquela fonte. Num contrato de serviço, isso é escopo do fornecedor. Numa ferramenta, é um projeto novo para o seu time.


O Que o Time de Segurança Vai Perguntar

Essas perguntas aparecem em todo questionário de fornecedor. Vale ter a resposta pronta antes de precisar dela.

  • Origem dos dados: somente fontes públicas oficiais e dados fornecidos pelo próprio cliente. Sem base própria de terceiros e sem revenda de cadastro.
  • Credencial: exclusiva por cliente, o que isola bloqueio e limita o alcance de qualquer incidente.
  • Tráfego: cifrado com TLS 1.3.
  • Auditoria: log de cada entrega, com data, fonte e retorno.
  • LGPD: conformidade por desenho, e não como camada aplicada depois. A fronteira do que se coleta é o que sustenta isso.

Vale registrar o que está fora do escopo, porque isso costuma ser perguntado: o serviço não é verificação de antecedentes, identidade ou score de crédito. Não é bureau. É engenharia de dados sobre fonte pública.


O Que o Time Técnico Vai Querer Testar

APIs disponíveis para o time integrar e validar o formato antes de qualquer coisa entrar em produção.
Entrega por API REST ou webhook, com payload documentado.
Formatos JSON, CSV, XLSX e XML, conforme o destino exigir.
Suporte 24/7 com quem opera a coleta, e não com um primeiro nível que abre chamado para outro time.

As Perguntas Que Separam Fornecedor de Revendedor

Antes de assinar, faça estas quatro. As respostas são curtas e reveladoras.

"Quando o portal muda, quem ajusta e em quanto tempo?" Se a resposta envolver orçamento adicional, você está comprando ferramenta com nome de serviço.

"O que o sistema devolve quando o captcha falha?" A única resposta aceitável é reprocessamento.

"Fica algum código de robô comigo?" Se ficar, a manutenção também fica.

"Como eu provo, seis meses depois, o que foi coletado no dia 12?" Sem log por entrega, não se prova.


Por Que Isso É Decisão de Negócio, e Não Técnica

Quem compra ferramenta herda a manutenção. Isso não é um detalhe operacional: é uma equipe permanente alocada para manter automações contra fontes que mudam sem aviso, para sempre.

No modelo de serviço, a automação é meio, não produto. A empresa contrata o dado atualizado no sistema dela e a continuidade disso é obrigação de quem opera.

A coleta é nossa. O risco também.


O teste que resolve a discussão

Se você já mantém automações internas contra portais públicos, o teste é simples: conte quantas horas do seu time foram gastas nos últimos três meses consertando robô que quebrou por mudança de fonte. Esse número é o custo escondido do modelo de ferramenta.

Se a conta fizer sentido, transferir esse risco começa por uma conversa com quem opera a coleta.


"Fonte pública muda de layout sem avisar. A pergunta não é 'se', é 'de quem é a conta'."
Assuntos
RPAManutençãoGovernançaLGPDTLSAuditoriaCaptchaContinuidade
Tem um caso parecido?

A gente coleta o dado na fonte e entrega dentro do seu sistema

Fale direto com quem constrói o robô. A conversa começa pela fonte, pelo volume e pelo destino do dado, não por proposta.