Toda organização sabe que possui TI paralela. O dado que torna o problema concreto: a maioria das organizações utiliza mais de 1,000 aplicativos em nuvem, e a TI geralmente tem visibilidade de menos de 10% deles. Grandes empresas utilizam, em média, 473 aplicativos SaaS; a TI gerencia diretamente apenas uma fração deles. Oitenta por cento dos funcionários utilizam aplicativos não autorizados para realizar seu trabalho. Os números são consistentes em todos os estudos porque a dinâmica que refletem é a mesma: funcionários e unidades de negócios adotam ferramentas que resolvem problemas imediatos mais rapidamente do que os processos de governança de TI conseguem avaliá-las e aprová-las.
A discussão sobre TI paralela em 2026 é dominada por ferramentas de descoberta de SaaS que examinam logs de DNS, analisam tokens OAuth de SSO, auditam relatórios de despesas e identificam o tráfego de rede para encontrar aplicativos em nuvem que os funcionários estão usando sem autorização. Essas ferramentas resolvem a camada SaaS do problema e o fazem razoavelmente bem. O que elas não resolvem, e o que nenhuma ferramenta de descoberta de SaaS aborda, é o outro problema da TI paralela: os aplicativos personalizados, os programas em lote não documentados, os pipelines de dados informais e os programas utilitários fantasmas que existem nos portfólios de aplicativos corporativos e nunca apareceram em nenhum sistema de gerenciamento de ativos, registro de alterações ou inventário de TI. Esses não são aplicativos em nuvem implantados por funcionários. São programas de produção, executados em mainframes e sistemas de médio porte, realizando funções críticas para os negócios que as organizações proprietárias não conseguem contabilizar completamente.
Os dois problemas exigem abordagens de descoberta diferentes. O problema da TI paralela em SaaS requer visibilidade da rede e integração de identidades. O problema da TI paralela em nível de código requer a análise dos artefatos de software reais — código-fonte, bibliotecas de carregamento, fluxos de tarefas JCL — para enumerar quais programas existem e o que fazem. Este guia aborda ambos os problemas, com foco específico na segunda categoria, que o restante da área ainda não explorou.
Os dois problemas da TI paralela
A TI paralela (Shadow IT) é geralmente definida como a tecnologia usada dentro de uma organização sem a aprovação ou o conhecimento explícito da TI. Essa definição abrange dois fenômenos fundamentalmente diferentes que exigem abordagens de descoberta e respostas de governança distintas.
SaaS e ferramentas em nuvem paralelas são aplicativos e serviços adotados por funcionários ou unidades de negócios sem a aprovação formal de um departamento de TI. Um exemplo é uma equipe de marketing usando uma ferramenta de escrita com IA não autorizada. Uma equipe de finanças compartilhando planilhas por meio de uma conta pessoal do Dropbox. Um desenvolvedor usando um assistente de codificação com IA não autorizado que envia código-fonte proprietário para uma API externa. Esses aplicativos existem fora da infraestrutura da organização e podem ser detectados por meio de sinais externos: consultas de DNS, autorizações OAuth, itens de relatórios de despesas, impressões digitais de tráfego de rede.
Software de aplicação paralelo , categoria na qual este artigo se concentra especificamente, refere-se a programas e processos em lote personalizados, criados dentro da própria infraestrutura da organização e que nunca foram devidamente documentados, inventariados ou controlados. Um exemplo é um programa COBOL escrito por um desenvolvedor do departamento financeiro em 1994 para lidar com um caso específico de cálculo de impostos. Outro exemplo é um programa RPG criado por um analista de negócios para gerar arquivos EDI para um parceiro comercial específico. Um job JCL executado mensalmente gera um relatório regulatório essencial para a equipe de compliance, desenvolvido por um contratado que deixou a organização em 2009. Por fim, um utilitário Java escrito "temporariamente" durante um projeto de integração de sistemas em 2018 tornou-se uma dependência permanente sem que ninguém decidisse que deveria.
Esses programas não são visíveis nos logs de DNS porque são executados em infraestrutura interna. Eles não aparecem nos registros de autorização OAuth porque são anteriores ao OAuth. Eles não estão no inventário oficial de aplicativos porque nunca foram formalmente submetidos à revisão de governança de TI. Eles só podem ser descobertos examinando a própria infraestrutura, as bibliotecas de carregamento, os repositórios de código-fonte, os agendadores de tarefas e os logs de execução que revelam qual software realmente é executado no ambiente.
A importância disso vai além da completude do inventário: 74% das organizações já sofreram incidentes de segurança devido a ativos desconhecidos ou não gerenciados. Softwares de aplicação não gerenciados representam a categoria de ativos desconhecidos que nem ferramentas de descoberta baseadas em rede nem plataformas de visibilidade de SaaS conseguem encontrar.
Por que o software de aplicativos não autorizados se acumula?
Compreender por que proliferam aplicações personalizadas não documentadas em ambientes empresariais explica por que os processos de governança padrão falham em impedi-las e por que a descoberta retrospectiva é necessária.
A necessidade de solução imediata. As unidades de negócio enfrentam problemas operacionais específicos que exigem soluções específicas. O aplicativo aprovado não lida com o caso extremo. A fila de solicitações de TI está sobrecarregada. Um desenvolvedor, às vezes da TI, às vezes integrado a uma equipe de negócios, cria uma solução que funciona. A solução é executada, resolve o problema e se torna parte do fluxo de trabalho operacional. O processo formal de governança nunca acontece porque o problema já foi resolvido.
O padrão temporário que se torna permanente. A forma mais insidiosa de software de aplicação paralelo começa como uma solução explicitamente temporária. "Só até o sistema real estar pronto." "Uma solução rápida para o problema de formato de dados." "Temporário enquanto esperamos o fornecedor corrigir a API." Soluções temporárias se tornam permanentes quando as dependências que se acumulam em torno delas nunca são desmanteladas. A correção de cálculo de data em COBOL escrita para a correção do bug do milênio (Y2K) que ainda é chamada vinte e cinco anos depois porque nenhum desenvolvedor subsequente sabia por que ela existia ou se era seguro removê-la. O script "temporário" de normalização de banco de dados que se tornou parte do lote noturno porque o aplicativo de destino nunca foi realmente construído.
A falha na transferência de conhecimento. Aplicativos paralelos, criados por indivíduos específicos, desaparecem do conhecimento documentado da organização quando esses indivíduos deixam a empresa. O programa continua em execução, está incorporado aos processos de produção que dependem dele, mas não há documentação, nenhum responsável é atribuído e ninguém sabe o que ele faz em detalhes suficientes para alterá-lo com segurança. Ele se torna um fantasma no ambiente de produção: visível em seus efeitos, invisível em sua governança.
O pipeline de dados paralelo. A integração de dados é um terreno particularmente fértil para softwares personalizados não documentados. Quando a camada ETL oficial não suporta uma transformação necessária, ou quando um processo de negócios exige que os dados se movam entre sistemas mais rapidamente do que o processo de integração oficial permite, os desenvolvedores criam programas não oficiais de movimentação de dados. Um script em Python que consulta o banco de dados de produção e grava os resultados em uma unidade compartilhada que um processo subsequente utiliza. Um programa em COBOL que lê do banco de dados DB2 do mainframe e grava em um arquivo plano que um aplicativo em nuvem ingere. Esses pipelines de dados não oficiais cruzam limites de sistemas, lidam com dados potencialmente sensíveis e operam completamente fora da estrutura de governança de integração.
As quatro categorias de software de aplicação paralela
Categoria 1: Aplicativos personalizados para unidades de negócios
Programas desenvolvidos por profissionais alocados em unidades de negócios, finanças, compras, operações e compliance, que resolvem problemas específicos de cada área. Esses programas normalmente:
- São nomeados informalmente (TAXCALC, VENDREPT, ADJBATCH) sem seguir as convenções de nomenclatura da empresa.
- Residir em diretórios ou bibliotecas gerenciadas pela unidade de negócios, e não pela TI.
- Não possui nenhuma entrada no banco de dados de gerenciamento de configuração (CMDB).
- Não há um responsável técnico atribuído no sistema de gestão de serviços de TI.
- Falta de documentação formal, cobertura de testes e histórico de controle de alterações.
A criticidade desses programas é frequentemente subestimada porque a unidade de negócios sabe o que eles fazem e os considera "deles". A área de TI, que desconhece a existência do programa, não consegue avaliar sua criticidade. A ausência do programa no inventário de aplicações de TI significa que ele está ausente do planejamento de continuidade de negócios (BCP), do planejamento de recuperação de desastres, das avaliações de segurança e do escopo do programa de modernização.
Categoria 2: Programas Fantasma
Programas que aparecem em execução em produção, mas cuja origem, propósito e propriedade são desconhecidos para a organização atual. Eles existem em bibliotecas de carregamento e repositórios de código-fonte, são chamados por outros programas ou invocados por tarefas JCL, produzem resultados dos quais processos subsequentes dependem, mas a memória organizacional sobre o porquê de sua existência e quem é responsável por eles se perdeu.
Programas fantasmas são particularmente perigosos do ponto de vista da segurança e da conformidade, pois não podem ser analisados de acordo com os padrões atuais, não podem ser incluídos em programas de varredura de vulnerabilidades que exigem a atribuição de propriedade do aplicativo e não podem ser avaliados quanto à conformidade regulatória, porque ninguém sabe a quais dados eles acessam ou qual função comercial desempenham.
Categoria 3: Pipelines de Dados Sombra
Programas não oficiais que transferem dados entre sistemas fora da arquitetura de integração oficial. Estes variam desde alternativas sofisticadas de ETL até scripts simples de transferência de arquivos:
python
# Typical shadow data pipeline -- production database to shared storage
# Written 2021, "temporary until the API is ready"
# Still running daily as of 2026, owner left organization 2022
import pyodbc, shutil
from pathlib import Path
conn = pyodbc.connect('DSN=PROD_BILLING;UID=svcacct;PWD=...') # hardcoded creds
cursor = conn.execute("SELECT * FROM BILLING_RECORDS WHERE STATUS = 'PENDING'")
rows = cursor.fetchall()
# Write to shared drive that Finance picks up
output_path = Path(r'\\FILESERVER01\Finance\billing_export.csv')
with output_path.open('w') as f:
for row in rows:
f.write(','.join(str(v) for v in row) + '\n')
shutil.copy(output_path, Path(r'\\ARCHIVE\billing\') / f"billing_{date.today()}.csv")Este programa, representativo de um padrão encontrado em ambientes corporativos, utiliza credenciais de banco de dados de produção embutidas no código, grava dados confidenciais de faturamento em um local de rede compartilhado sem criptografia e está em execução sem monitoramento há anos, mesmo após a saída do autor da organização. Ele não seria detectado por nenhuma ferramenta de descoberta de SaaS, pois é executado em infraestrutura interna. Também não seria detectado por análises de tráfego de rede, pois utiliza protocolos de banco de dados padrão que não produzem nenhuma assinatura identificável. Sua visibilidade se restringe ao próprio código-fonte.
Categoria 4: Tarefas em lote não documentadas
Fluxos de tarefas JCL e programas agendados que são executados na infraestrutura de produção, mas que não constam na documentação oficial de agendamento de tarefas. Eles se acumulam por meio de:
- Tarefas enviadas fora do agendador de tarefas padrão por meio de envio direto.
- Programas chamados dinamicamente de dentro de outros programas (e, portanto, não visíveis independentemente nos inventários do agendador)
- Tarefas que são executadas com pouca frequência, no final do mês, no final do ano ou apenas quando ocorrem condições comerciais específicas, e que nunca foram registradas em auditorias de estoque de rotina.
- Tarefas herdadas de sistemas predecessores que foram "migrados", mas nunca formalmente desativados.
Tarefas em lote não documentadas tornam-se pontos críticos de falha quando:
- Uma janela de manutenção afeta o sistema em que eles são executados, e ninguém sabe que precisa notificar a unidade de negócios que depende da sua produção.
- É realizada uma avaliação de segurança e essas tarefas são executadas como contas de serviço não monitoradas com privilégios elevados.
- Um programa de modernização define o escopo da migração com base no cronograma de tarefas documentado e chega ao ambiente de destino sem processamento em lote crítico.
Métodos de descoberta por categoria de software Shadow
Os métodos de descoberta adequados para TI paralela em SaaS são, em grande parte, inaplicáveis a softwares de aplicação paralelos. Os métodos necessários são:
Análise da biblioteca de carregamento. Todo programa que já foi compilado e implantado em um sistema mainframe ou midrange existe em uma biblioteca de carregamento, o repositório de executáveis. A comparação entre os programas na biblioteca de carregamento e os programas no inventário oficial de aplicativos revela a lacuna: todo módulo de carregamento que aparece na biblioteca, mas não no inventário, é um programa oculto. Esta análise não requer código-fonte; ela opera nos executáveis compilados e seus metadados.
Percorrer o repositório de código-fonte. Os repositórios de código-fonte (PDSs de código-fonte COBOL, repositórios Git, bibliotecas de código-fonte RPG) contêm todos os programas já escritos, incluindo programas escritos informalmente, implantados informalmente e nunca registrados em sistemas de governança de TI. Percorrer todo o repositório de código-fonte em relação ao CMDB revela programas que existem no código-fonte, mas não possuem registro de governança.
Conciliação de JCL e agendador. Cada fluxo de trabalho JCL executado em produção, seja submetido pelo agendador oficial, manualmente ou invocado por outro trabalho, deixa um rastro no log de execução do trabalho (JESLOG, SYSLOG). A comparação dos programas que aparecem nos logs de execução de produção com os programas no inventário oficial identifica os programas que são executados em produção sem cobertura de governança.
Análise dinâmica de chamadas (CALL). Programas que chamam outros programas dinamicamente, onde o nome do programa chamado é determinado em tempo de execução em vez de em tempo de compilação, criam dependências invisíveis para a análise estática do escalonador. A análise dinâmica de chamadas rastreia quais programas emitem instruções CALL com nomes de programas variáveis, identifica o intervalo de programas que podem ser chamados e sinaliza programas alcançáveis por meio de despacho dinâmico que podem não aparecer em nenhum mapa de dependências estático.
Rastreamento do fluxo de dados. Pipelines de dados paralelos são detectáveis por meio da análise de padrões de acesso ao sistema de arquivos e ao banco de dados: quais programas leem ou gravam em quais conjuntos de dados, arquivos ou tabelas de banco de dados. Um programa que lê de um banco de dados de produção e grava em um caminho de arquivo fora da hierarquia padrão de gerenciamento de dados é um candidato a pipeline paralelo.
A Dimensão da IA Sombria
A extensão do problema da TI paralela em 2026 é a IA paralela, ou seja, funcionários e unidades de negócios que utilizam ferramentas e agentes de IA sem autorização da TI. De acordo com o relatório da IBM "Custo de uma Violação de Dados em 2026", 43% dos incidentes de segurança envolvem funcionários que utilizam IA paralela. A Gartner prevê que, até 2030, mais de 40% das empresas sofrerão um incidente de segurança ou de conformidade relacionado à IA paralela não autorizada.
O risco específico introduzido pela IA paralela, diretamente relevante para a TI paralela em nível de código, é o código-fonte proprietário inserido em assistentes de codificação de IA. Um funcionário que utiliza um assistente de codificação de IA não autorizado para auxiliar em um programa COBOL legado envia o código-fonte desse programa para um provedor externo de IA. O código-fonte pode conter credenciais embutidas, lógica de negócios que constitui segredo comercial ou estruturas de dados cuja exposição viola os requisitos de residência de dados. O método de detecção para esse risco específico não é a análise do tráfego de rede, mas sim a identificação de quais programas foram acessados por ferramentas que se comunicam com APIs de IA externas, o que exige monitoramento em nível de aplicação, e não em nível de rede.
O problema da IA oculta e o problema do software de aplicação oculto compartilham uma característica importante: ambos são invisíveis para as ferramentas de descoberta baseadas em rede que dominam o mercado de TI oculta em SaaS. Ambos exigem monitoramento em nível de aplicação ou análise estrutural do código para serem revelados.
Construindo o Inventário Completo de Aplicativos
O resultado de um programa de descoberta de TI paralela para software de aplicativos empresariais é um inventário consolidado que abrange quatro grupos:
Conhecidos e documentados: Programas que constam tanto no inventário oficial quanto no ambiente de produção real. Esses programas possuem governança, responsáveis atribuídos, histórico de controle de alterações e planos de recuperação de desastres.
Conhecidos, mas não implantados: Programas que constam no inventário oficial, mas não são encontrados nas bibliotecas de carga ou nos registros de execução de produção. Esses programas são candidatos à desativação, podem ter sido desativados sem o devido processo legal ou podem estar listados incorretamente.
Programas desconhecidos, mas implantados (programas paralelos): Programas que aparecem em logs de execução de produção ou bibliotecas de carregamento, mas não possuem registro no inventário oficial. Esses são os principais achados de TI paralela, programas que exigem atribuição imediata de responsabilidade, avaliação de segurança e registro de governança.
Dependências não documentadas: Programas que não constam no inventário oficial nem nos logs de execução de produção principais, mas são descobertos por meio de análise dinâmica de chamadas (CALL) ou rastreamento de fluxo de dados como acessíveis a partir de processos de produção. Esses são os programas fantasmas, os mais difíceis de encontrar e os mais perigosos de se deixarem passar despercebidos.
A conciliação entre essas quatro populações resulta no plano de ação: registrar os programas paralelos, avaliar seu nível de segurança, atribuir responsabilidades e determinar sua destinação, governá-los e mantê-los, modernizá-los ou desativá-los.
Como SMART TS XL Realiza descoberta de TI paralela em nível de código
SMART TS XLA abordagem da [nome da empresa] para a descoberta de TI paralela aborda as categorias de nível de código que as ferramentas baseadas em rede não conseguem alcançar.
A capacidade de análise estática de código começa com a varredura completa do repositório de código-fonte: cada programa COBOL, módulo RPG, aplicação PL/I, serviço Java, script Python e fluxo de trabalho JCL no ambiente é catalogado com sua localização de origem, linguagem, tamanho e perfil de complexidade preliminar. Esse inventário é a base para a reconciliação do CMDB e do registro oficial de aplicações; os programas que aparecem no repositório de código-fonte, mas não no inventário oficial, são a principal descoberta de aplicações paralelas.
O mapeamento de dependências de aplicativos resolve o problema de chamadas dinâmicas (CALL): ao rastrear cada instrução CALL em cada programa, incluindo chamadas dinâmicas onde o nome do programa é uma variável, o mapa de dependências identifica programas que são acessíveis a partir de processos de produção, mesmo quando nunca aparecem nos inventários estáticos do agendador. Um programa fantasma que é chamado dinamicamente por dez programas de produção aparece no mapa de dependências mesmo que não tenha uma definição de tarefa JCL independente.
A funcionalidade de expansão de JCL rastreia toda a cadeia de execução de cada fluxo de trabalho JCL: resolvendo referências PROC, expandindo parâmetros simbólicos e construindo o mapa completo dos programas que cada trabalho invoca. Quando esse mapa é comparado com a documentação oficial de agendamento de tarefas, os trabalhos e programas que são executados em produção sem cobertura de documentação são identificados automaticamente.
A capacidade de análise de impacto torna as descobertas acionáveis: para cada programa paralelo identificado, enumere todos os processos de produção que dependem dele. Um programa paralelo sem dependências é um candidato a código morto, seguro para ser desativado. Um programa paralelo com vinte dependências de produção é um ativo crítico não documentado que requer atenção imediata da governança. O escopo do impacto é o que determina a prioridade de remediação.
A funcionalidade de busca corporativa permite consultar todo o inventário: encontre todos os programas que acessam um conjunto de dados específico (potenciais candidatos a pipelines de dados paralelos), todos os programas escritos após uma data específica que não possuem entrada no CMDB (aplicativos paralelos recentes) e todos os programas que gravam em caminhos de arquivos externos fora da hierarquia padrão de gerenciamento de dados. Essa funcionalidade de busca auxilia tanto na descoberta inicial quanto no monitoramento contínuo, impedindo que o acúmulo de aplicativos paralelos seja retomado após a limpeza inicial.
Para organizações que realizam programas de modernização de sistemas legados , a descoberta de aplicações paralelas é uma etapa fundamental. Um programa de modernização que define o escopo da migração com base no inventário oficial de aplicações e descobre aplicações paralelas durante a execução é um programa cujo escopo, cronograma e orçamento estavam todos errados no momento do planejamento. A descoberta que deveria ter ocorrido antes do planejamento agora está acontecendo durante a execução, quando seu custo é mais alto.
A resposta da governança: não bloquear, mas dar visibilidade.
As organizações que gerenciarem a TI paralela de forma eficaz em 2026 aprenderam que a proibição total não funciona e cria incentivos perversos. A denúncia de TI paralela falha na maioria das organizações por um motivo: os funcionários esperam punição. Quando um membro da equipe financeira usa um rastreador de despesas não aprovado e o denuncia, uma equipe de segurança que responde com uma repreensão acaba ensinando esse funcionário, e todos com quem ele conversa, a se manterem em silêncio na próxima vez.
O mesmo princípio se aplica a softwares de aplicação não autorizada. Um desenvolvedor que criou um utilitário COBOL essencial para os negócios da organização não deve ser punido por não ter passado por um processo de governança que pode não ter sido claramente comunicado na época. A resposta da governança à descoberta de aplicações não autorizadas deve ser:
Registro, não remoção. Programas ocultos que se mostram críticos para os processos de negócio não devem ser removidos, mas sim aplicações de produção não documentadas que exigem governança. Registre-os, atribua responsáveis, avalie seu nível de segurança e trate-os com a mesma disciplina de governança que qualquer outra aplicação de produção.
Anistia para autodenúncia. Um programa de governança que cria canais seguros para que as unidades de negócios divulguem aplicativos informais que desenvolveram revela softwares não autorizados mais rapidamente do que qualquer abordagem de descoberta técnica. A garantia de que a divulgação leva ao apoio da governança, auxílio com a documentação, revisão de segurança e registro formal, em vez de medidas disciplinares, elimina o incentivo ao ocultamento.
Prevenção por meio de processos. A causa principal do acúmulo de aplicações paralelas é o atrito na governança: o processo oficial para solicitar o desenvolvimento de novas aplicações é mais lento do que o necessário para atender às necessidades do negócio. Reduzir esse atrito, por meio de uma governança de desenvolvimento ágil e simplificada, suporte de governança de TI integrado às unidades de negócio e aprovação simplificada para ferramentas internas de baixo risco, reduz a taxa de criação de novas aplicações paralelas sem exigir uma investigação técnica contínua.
O estoque que você pensa ter não é o estoque que você realmente tem.
A diferença entre o inventário de aplicativos mantido pela TI e o software aplicativo que de fato roda em ambientes corporativos não é uma discrepância insignificante. Em grandes organizações com décadas de acúmulo de aplicativos, a lacuna entre o documentado e o real pode chegar a 30% do total de programas. Os 30% não documentados incluem programas que processam dados sensíveis, executam funções de conformidade regulatória, estão no caminho crítico dos processos de negócios e apresentam vulnerabilidades de segurança que ninguém revisou porque ninguém sabia que precisavam ser revisadas.
As ferramentas de descoberta de TI paralela (shadow IT) em SaaS abordam bem a camada de nuvem desse problema. O problema da TI paralela em nível de código — os programas personalizados, utilitários fantasmas, pipelines de dados informais e jobs em lote não documentados que povoam os ambientes legados corporativos — exige uma abordagem diferente: a análise estrutural dos artefatos de software reais, em vez do monitoramento do tráfego de rede. O inventário que emerge dessa análise costuma ser surpreendente em sua abrangência. As organizações que realizam esse trabalho descobrem consistentemente que o que pensavam ter em produção e o que realmente está em execução são duas coisas significativamente diferentes. Preencher essa lacuna é a base de todo programa de governança, segurança, continuidade de negócios (BCP) e modernização que depende do conhecimento do que a organização realmente opera.
