Como a IA Generativa transformou minha rotina de sustentação — e por que o ganho real não é velocidade
Quem sou e onde atuo
Sou Vanessa Mendes, estagiária na área de Telecom. Nos últimos 4 meses (abril a julho de 2026), minha rotina envolveu manter operações de telefonia cloud para múltiplos clientes — cada um com stack diferente, particularidades de infraestrutura e urgências distintas.
O ecossistema que sustento inclui:
- Amazon Connect (filas, flows, callbacks, views) para grandes operações
- PBX Issabel/Asterisk (on-premises em EC2) para operações menores
- AWS (Lambda, DynamoDB, S3, CloudWatch, Security Groups)
- Jira + Confluence (gestão de tickets e documentação)
Atuo dentro de um time de sustentação Telecom onde o compartilhamento de conhecimento é constante e a colaboração faz parte da rotina.
Em paralelo ao trabalho de sustentação, adotei o Kiro CLI — um assistente de IA que se integra ao ambiente de trabalho via MCPs (Model Context Protocol) — como ferramenta complementar de produtividade. Esse artigo não é sobre a ferramenta em si. É sobre como a IA mudou a forma do meu trabalho.
O desafio: múltiplos clientes, múltiplos sistemas, decisões rápidas
Para contextualizar: atendo múltiplos clientes simultaneamente, cada um com seus acessos AWS, perfis SSO, instâncias Connect, PBXs e particularidades. Um ticket de incidente pode exigir:
- Ler o ticket no Jira (contexto)
- Acessar CloudWatch Logs (evidência)
- Verificar Security Groups ou DynamoDB (infraestrutura)
- Consultar documentação no Confluence (histórico)
- Conectar via SSH em um PBX (diagnóstico)
- Cruzar com tickets anteriores do mesmo cliente (padrão)
Antes da IA, cada salto entre sistemas consumia tempo e introduzia risco de perder contexto. A investigação dependia fortemente da minha memória e experiência — o que, com 4 meses de empresa, era uma limitação real. O time Telecom sempre esteve disponível para tirar dúvidas e validar hipóteses, mas ter uma ferramenta que me ajudasse a organizar informações e manter contexto entre sistemas foi um divisor de águas.
O que entreguei no primeiro semestre
1. Sistema de Callback: 4 versões até a produção
Meu principal projeto foi o desenvolvimento completo de um sistema de callback para Amazon Connect, evoluído por 4 versões:
| Versão | O que resolveu |
|---|---|
| v1 | Oferta básica de retorno de ligação |
| v2 | Detecção de ramal/central + captura de número alternativo + suporte a 11 DDIs internacionais |
| v3 | Confirmação por últimos 4 dígitos (resolve leitura confusa do Polly) |
| v4 | Fluxo unificado + Lambda Python + validação de discabilidade nativa |
O resultado final: um Flow Module com 113 blocos, suporte a 3 idiomas (PT/EN/ES), uma Lambda Python 3.12 que concatena números internacionais, e uma descoberta técnica que eliminou uma Lambda inteira do fluxo — o bloco UpdateContactCallbackNumber funciona como validador de discabilidade.
A documentação completa foi publicada no Confluence. Com a IA como apoio na organização, o tempo entre "código pronto" e "documentação publicada" diminuiu consideravelmente.
2. Sistema de Prioridade VIP: gerenciamento inteligente
Desenvolvi um sistema de gerenciamento de clientes VIP no workspace do Amazon Connect:
- View com tabela editável (inline editing) para supervisores
- Lambda Python com 5 ações de CRUD
- DynamoDB on-demand para armazenamento
- Prioridade na fila (Priority 1) + Whisper Flow de identificação
Um ponto importante: a primeira versão da View foi gerada pela IA nativa do Amazon Connect. Falhou com erros de schema, TableAction undefined e campos genéricos. A solução que funcionou foi criar manualmente usando BlockList como template. A IA não é infalível — validação humana é inegociável.
3. Correção de pesquisa CSAT: auditoria de dados em escala
Um bug que existia há quase 2 meses fazia pesquisas de satisfação serem gravadas com o ID errado — mais de mil chamadas afetadas, quase 200 com notas incorretas no DynamoDB.
Com apoio da IA:
- Identifiquei o root cause (3 nodes do flow com IDs trocados)
- Gerei um script retroativo com modo
DRY_RUN, backup e validação condicional - Mapeei 270+ registros no DynamoDB para correção
- Produzi um laudo de validação para aprovação do supervisor
Esse tipo de trabalho — auditoria em escala com segurança — seria impraticável manualmente no tempo disponível.
4. Incidentes resolvidos: a investigação como diferencial
| Incidente | Causa raiz | Como a IA ajudou |
|---|---|---|
| Painel de estatísticas offline | IP alterado pelo cliente, não estava no Security Group | Cruzamento de evidências (DNS, TCP, Apache, iptables) de forma estruturada |
| Disco cheio no PBX (>90%) | Gravações acumuladas sem limpeza automática | Geração do procedimento operacional + recomendação de automação |
No total, fui assignee em ~20 tickets no período.
O insight: a IA não economiza tempo — ela transforma o trabalho
Se alguém me perguntar "quanto tempo a IA economiza?", minha resposta honesta é: pouco. Meu calendário não ficou vazio. O que mudou foi o tipo de trabalho que faço.
Antes (sem IA):
- Hipóteses baseadas em experiência limitada (4 meses de empresa)
- Documentação como "dívida técnica" — feita às pressas ou nunca
- Investigação linear: verificar um sistema por vez, perder contexto entre saltos
Depois (com IA):
- Cruzamento de múltiplas fontes → hipóteses fundamentadas em dados
- Documentação como subproduto natural do trabalho
- Investigação estruturada: IA mantém contexto enquanto eu navego entre sistemas
A métrica que importa não é "horas economizadas". É:
| Métrica tradicional | Métrica real de impacto |
|---|---|
| Tempo por ticket | Profundidade da análise por ticket |
| Volume de docs | Qualidade e reuso da documentação |
| Tickets/dia | First-call resolution rate |
| Horas economizadas | Decisões com dados completos |
Da teoria à prática: a jornada de estudo e implementação
O primeiro semestre foi dividido em duas fases claras:
Fase 1 — Estudo e absorção (Abril–Junho)
De abril a junho, meu foco foi consumir conteúdo e construir base teórica. Participei de 6 workshops (~22h) — desde fundamentos de Amazon Connect até workshops de nível 400 sobre IA Agente — e completei ~11h de cursos autônomos no AWS Skill Builder.
Os workshops mais transformadores:
- KiroOps (Nível 300, 4h) — onde entendi o potencial do Kiro para análise de código e documentação
- Blackbelt IA Agente (Nível 400, 5h) — onde consolidei a teoria com prática real usando Kiro + SSO corporativo
- CX Autônomo com MCP + Salesforce (Nível 300, 3h) — orquestração de agentes autônomos em contact centers
Obtive o badge Amazon Connect AI Fundamentals.
Fase 2 — Prática e construção (Julho)
Em julho, decidi sair da teoria e começar a aplicar IA no meu dia a dia de forma estruturada.
Criei um time-tracker — um projeto pessoal de controle de horas onde registro cada ticket com descrição e tempo investido. Esse foi meu primeiro projeto construído com apoio ativo de IA generativa no processo de desenvolvimento.
Em seguida veio um dashboard de sustentação — 13 páginas, 28 endpoints e integrações com Jira, Confluence e AWS CLI. Esse projeto consolidou tudo: a prática com IA no desenvolvimento, o conhecimento técnico adquirido na sustentação, e a organização da minha rotina.
Quando a IA falha
Seria desonesto falar apenas dos acertos:
- View VIP gerada pela IA nativa do Connect — falhou com erros de schema não documentados. A solução veio de engenharia reversa manual.
- Sugestões de comandos SSH — a IA não tem visibilidade do estado real do servidor. Comandos precisam ser validados antes de executar.
- Flows com 100+ blocos — contextos que excedem a janela da IA. É necessário segmentar a análise.
A lição: o profissional que usa IA precisa de MAIS conhecimento técnico, não menos. A IA amplifica competência — não a substitui.
Números do semestre
| Indicador | Valor |
|---|---|
| Projetos em produção | 2 |
| Projetos em DEV | 1 |
| Incidentes com root cause documentada | 4 |
| Tickets como assignee | ~20 |
| Páginas Confluence publicadas | 4 |
| Documentos técnicos locais | 9 |
| Workshops/eventos | 6 (~22h) |
| Cursos autônomos | ~11h |
| Badge AWS | 1 (Amazon Connect AI Fundamentals) |
| Projetos pessoais com IA | 2 |
Agradecimento ao time Telecom
Nenhuma dessas entregas teria acontecido sem o time de Sustentação Telecom. Agradeço a todo o time pela paciência, disponibilidade e pela cultura de colaboração que torna possível crescer rápido mesmo sendo iniciante.
Em especial, agradeço ao Carlos e ao Wallace — as dicas técnicas compartilhadas no dia a dia, o raciocínio rápido para diagnóstico e a generosidade em explicar aceleraram minha curva de aprendizado de forma que nenhuma ferramenta substitui. A agilidade nas questões técnicas, os atalhos que economizam horas de tentativa e erro — isso é mérito de pessoas reais, disponíveis e generosas com o tempo delas.
A IA Generativa é uma ferramenta poderosa, mas o conhecimento que me permitiu usá-la com eficácia veio do time.
Conclusão: de operadora reativa a investigadora proativa
Em 4 meses, saí de "primeira experiência com Amazon Connect" para ter um sistema de 113 blocos em produção, um bug de dados auditado em escala, e autonomia crescente para resolver incidentes.
A IA Generativa não fez isso por mim. Ela mudou a forma como abordo cada problema:
- Antes: reativa, linear, limitada pela memória
- Depois: proativa, estruturada, fundamentada em dados
Para quem está começando na área: a IA não é atalho. É alavanca. Funciona melhor quando você sabe o que está fazendo — e transforma completamente quando você tem um time que te apoia enquanto você ainda está aprendendo.
Gostou? Me segue aqui no Dev.to para mais artigos sobre AWS, GenAI e operações cloud. 🚀
Top comments (0)