A pressa é a inimiga da perfeição!

Introdução

O avanço acelerado da inteligência artificial (IA) em setores como finanças, saúde, varejo e administração pública tem impulsionado uma transformação profunda na engenharia de software. Aplicações baseadas em IA — como sistemas de recomendação, detecção de fraudes e apoio ao diagnóstico médico — já impactam milhões de pessoas e estão cada vez mais presentes em decisões críticas.

Entretanto, essa adoção em larga escala escancara fragilidades nos processos tradicionais de desenvolvimento, exigindo que repensemos qualidade, manutenção e sustentabilidade de sistemas. Um conceito central nesse debate é o de dívida técnica, cunhado por Ward Cunningham em 1992. Assim como uma dívida financeira viabiliza ganhos imediatos ao custo de compromissos futuros, a dívida técnica refere-se às consequências de atalhos tomados para acelerar entregas — como pular testes, documentações ou refatorações. Com o tempo, esse passivo aumenta a complexidade, eleva os custos de manutenção e reduz a capacidade de evolução do sistema. Em outras palavras: A dívida precisa ser paga.

Nos sistemas tradicionais, essas dívidas se manifestam em código mal estruturado, design deficiente, arquitetura inflexível e pouca cobertura de testes. Em soluções de Machine Learning (ML), a situação é ainda mais complexa: além de herdar as dívidas clássicas, modelos de IA introduzem novas fontes de passivo ligadas à sua natureza dinâmica, estatística e, muitas vezes, opaca. Entre os principais fatores: - Dependência de dados instáveis ou enviesados - Dificuldade de rastrear experimentos, versões e configurações - Baixa ou nenhuma interpretabilidade de decisões do modelo - Riscos de retroalimentação invisível — por exemplo, em sistemas de recomendação, o modelo prioriza os itens mais clicados, reforçando padrões e ignorando alternativas relevantes.

O comportamento de um sistema de IA não é determinado apenas pelo código, mas por uma combinação entre dados, modelo e ambiente de operação. Essa característica compromete atributos como testabilidade, reprodutibilidade e auditabilidade, e impõe desafios éticos, regulatórios e de transparência.

Mini-exemplo: “juros compostos” da dívida técnica

Imagine um sistema de recomendação que não é reavaliado por anos. Ele continua oferecendo resultados obsoletos, reduzindo a eficácia da experiência do usuário e, eventualmente, obrigando uma reestruturação completa do pipeline. Esse efeito de degradação acumulada ilustra os juros compostos da dívida técnica: quanto mais se adia a correção, maior o impacto.

Com a tecnologia no centro das decisões estratégicas, torna-se essencial compreender as origens e implicações da dívida técnica em sistemas baseados em IA. Só assim será possível desenvolver soluções mais robustas, auditáveis e sustentáveis — tanto do ponto de vista técnico quanto organizacional e social.

Particularidades de sistemas de ML

Soluções de aprendizado de máquina seguem um ciclo contínuo e interdependente que vai da coleta de dados à operação em produção. Esse ciclo é composto por diferentes etapas, cada uma com suas próprias exigências técnicas e potenciais fontes de dívida técnica.

Tudo começa na aquisição e análise de dados, que envolve a coleta de informações de diferentes fontes e a avaliação de sua qualidade, completude e relevância. Em seguida, realiza-se a preparação dos dados, etapa crítica que inclui limpeza, transformação, normalização e engenharia de atributos. Um erro nessa fase pode comprometer todo o sistema downstream.

Com os dados preparados, inicia-se a experimentação de modelos, em que diferentes algoritmos, arquiteturas e configurações são testados. Após essa exploração, o modelo escolhido é treinado, ajustando seus parâmetros para maximizar o desempenho.

Concluído o treinamento, é preciso realizar a validação do modelo com dados não vistos, garantindo sua generalização e robustez. Quando atinge desempenho satisfatório, o modelo é implantado — geralmente como uma API — e entra em fase de monitoramento. Métricas como acurácia, latência e variações de distribuição de dados ajudam a identificar quando é necessário o retreinamento.

Cada uma dessas etapas pode acumular dívida técnica caso não seja tratada com cuidado — e quanto mais invisível a dívida, maior seu potencial destrutivo no longo prazo.

Taxonomia dos débitos

Aqui organizo as dívidas técnicas em três grupos: estrutural, algorítmica e sociotécnica. Esta taxonomia baseia-se em estudos consolidados sobre dívida técnica em IA, referênciados ao final do texto, e visa facilitar a análise prática desses problemas. Embora não seja uma taxonomia oficial consolidada, ela sintetiza abordagens recorrentes encontradas na literatura técnica e empírica recente.

Dívidas estruturais

As dívidas estruturais dizem respeito aos alicerces técnicos do sistema. Comprometem escalabilidade, reprodutibilidade e rastreabilidade, e são críticas desde os primeiros ciclos do projeto.

Tabela 1 – Tipos de dívida estrutural em sistemas de ML

Tipo de dívida	Descrição	Exemplos
Code Debt	Código mal estruturado, acoplado ou não testado. Prejudica reuso e manutenção.	Código duplicado, ausência de testes, lógica embaralhada em notebooks.
Architecture Debt	Estruturas rígidas e monolíticas que dificultam a evolução ou reuso de componentes.	Pipeline acoplado, ausência de camadas, retrabalho a cada novo experimento.
Infrastructure/Operational	Falta de automação, escalabilidade ou confiabilidade na operação do sistema.	Deploys manuais, ausência de logging, latência alta sem alerta.
Configuration Debt	Parâmetros e configurações hardcoded, inconsistentes ou não versionados.	.env divergentes, hiperparâmetros soltos no código, sem histórico de execuções.
Versioning & Build Debt	Falta de versionamento de código, dados e modelos. Afeta reprodutibilidade e comparabilidade.	Sem Git, ausência de MLflow ou DVC, builds manuais com dependências frágeis.
Documentation & Knowledge	Ausência de documentação técnica e decisões de projeto. Gera dependência de conhecimento tácito.	README ausente, decisões arquivadas apenas em chats, ausência de histórico de mudanças.
External Dependency Debt	Dependência de bibliotecas ou APIs externas instáveis, não testadas ou não versionadas.	Atualização de pacote que quebra compatibilidade com código legado.

Dívidas algorítmicas

Estas dívidas são específicas da natureza estatística, iterativa e dependente de dados dos sistemas de ML.

Tabela 2 – Tipos de dívida algorítmica em sistemas de ML

Tipo de dívida	Descrição	Exemplos
Data Debt	Dados inconsistentes, desatualizados ou sem governança afetam diretamente a qualidade do modelo.	Dados com erro, schema mutável, origem não rastreada, ausência de validação ou limpeza.
Model Debt	Modelos mal ajustados, não auditados ou obsoletos.	Overfitting (modelo memoriza dados e não generaliza), ausência de baseline, explainability nula.
Testing & Monitoring	Falta de testes automatizados e monitoramento contínuo em produção.	Nenhum alerta para concept drift (mudança no padrão de dados), testes apenas offline.
Experiment Tracking Debt	Execuções e hiperparâmetros não rastreados comprometem replicação e avaliação.	Treinos locais em notebooks sem MLflow ou controle de versões.
Feedback Loops	O modelo influencia os dados futuros e gera vieses autocumulativos.	Recomendador que prioriza itens mais clicados reforça padrões e exclui diversidade.

Dívidas sociotécnicas

Relacionam-se à cultura, organização e valores humanos envolvidos no desenvolvimento de sistemas de IA.

Tabela 3 – Tipos de dívida sociotécnica

Tipo de dívida	Descrição	Exemplos
Ethics Debt	Falta de consideração a princípios como justiça, transparência e responsabilidade algorítmica.	Modelo com viés contra grupos minoritários, decisões automatizadas sem explicação.
People/Social Debt	Concentração de conhecimento, ausência de repasse formal ou dependência de práticas informais.	Pipeline compreendido por uma única pessoa, ausência de onboarding estruturado.
Organizational/Process	Falta de colaboração entre times, desalinhamento entre metas técnicas e de negócio, processos frágeis.	Cientistas de dados e devops desalinhados, requisitos mal traduzidos, ausência de workflows claros.
Regulatory Debt	Falta de conformidade com regulamentações (ex.: GDPR, AI Act), ausência de auditoria ou mecanismos formais.	Sistema sem log de decisões automatizadas, ausência de consentimento informado, falta de rastreio.

Conclusão

A dívida técnica em IA é multifacetada, abrangendo aspectos clássicos da engenharia de software e novos desafios trazidos por dados, modelos e contextos sociais. Ela pode comprometer não apenas a performance, mas também a confiabilidade, auditabilidade e integridade dos sistemas.

Referências

• Pepe, F., Zampetti, F., Mastropaolo, A., Bavota, G., & Di Penta, M. (2024). A Taxonomy of Self-Admitted Technical Debt in Deep Learning Systems arXiv:2409.11826.
• Recupito, G., Pecorelli, F., Catolino, G., Lenarduzzi, V., Taibi, D., Di Nucci, D., & Palomba, F. (2024). Technical Debt in AI-Enabled Systems: On the Prevalence, Severity, Impact, and Management Strategies for Code and Architecture Journal of Systems and Software, 216, 112151.
• O’Brien, D., Biswas, S., Imtiaz, S., Abdalkareem, R., Shihab, E., & Rajan, H. (2022). 23 Shades of Self-Admitted Technical Debt: An Empirical Study on Machine Learning Software In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2022).
• Bogner, J., Verdecchia, R., & Gerostathopoulos, I. (2021). Characterizing Technical Debt and Antipatterns in AI-Based Systems: A Systematic Mapping Study In IEEE/ACM International Conference on Technical Debt (TechDebt).
• Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J. F., & Dennison, D. (2015). Hidden Technical Debt in Machine Learning Systems. In Advances in Neural Information Processing Systems (NeurIPS).
• Cunningham, W. (1992). The WyCash Portfolio Management System. Apresentado na OOPSLA.