Os Centros Globais de Competências (GCCs) na Índia, que anteriormente funcionavam como divisões de corporações multinacionais responsáveis por todo o leque de tarefas — desde finanças até engenharia e suporte ao cliente — foram considerados por muito tempo principalmente como centros de custos, e não como estruturas que formam tecnologias. No entanto, essa concepção está se tornando obsoleta.
Quinn George, líder em IA e GCC, observou na conferência DevSparks Chennai 2026 que os GCCs na Índia estão se transformando em centros nodais para o desenvolvimento de produtos, plataformas e inovações, e não apenas para a execução de pedidos. Sua apresentação, intitulada «Do código ao impacto de negócios: O que os GCCs na Índia realmente criam?», focou no papel dos desenvolvedores como força motriz dessas transformações e nas exigências feitas a eles.
George destacou três tendências principais observadas nos GCCs. Primeiro, a automação: segundo sua avaliação, 50–60% dos GCCs estão implementando automação para operações rotineiras e de alto volume, como o processamento de solicitações em serviços de suporte, que antes exigiam participação humana constante. Segundo, a transição para total responsabilidade. Em vez de criar uma pequena parte de um produto global, alguns GCCs agora desenvolvem sistemas inteiros do início ao fim, citando um GCC que é totalmente responsável pelo desenvolvimento de um sistema de gestão de crédito para um cliente bancário. Terceiro, observa-se um aumento acelerado de especialistas em engenharia de IA, embora George tenha reconhecido que para muitas organizações ainda seja incerto quais produtos devem ser criados com essas novas equipes.
Uma parte significativa dessa atividade é motivada pelo medo de ficar de fora (FOMO) — tanto por parte das empresas multinacionais que competem pela criação de GCCs na Índia quanto pelos próprios GCCs, que buscam não ficar para trás no campo da IA. Essa urgência levou a resultados tangíveis: George apontou para empresas que utilizam dois tipos de cenários de aplicação de IA — aqueles que afetam diretamente a receita e oferecem retorno de investimento visível, e aqueles voltados para aumentar a produtividade interna.
O principal aviso de George diz respeito a um fenômeno que ele chamou de «cemitério de pilotos» — situações em que vitórias em hackathons e conceitos comprovados são celebrados uma vez, e depois não são mais testados. Ele enfatizou que é crucial que os funcionários dos GCCs, ao passar da ideia para a solução pronta, considerem a sustentabilidade a longo prazo. Na sua opinião, esta é a maior lacuna.
Ele argumentou que uma ideia que parece convincente em um modo piloto controlado ainda deve passar por testes em operação real e corrente, bem como na capacidade de se adaptar às necessidades comerciais em mudança e manter o interesse do usuário após a novidade passar. Um piloto forte não garante sucesso a longo prazo.
George ligou este problema à prática comum nos GCCs: as equipes primeiro desenvolvem um produto que, em sua opinião, está correto, e depois tentam vendê-lo ao negócio. Ele considera que essa abordagem é inversa. Em vez disso, os engenheiros devem interagir diretamente com as equipes de negócios e clientes, identificando problemas por conta própria, em vez de esperar por um termo de referência técnico formal.
A mudança no que os GCCs criam afeta os requisitos para os desenvolvedores. George observou que esses desenvolvedores não têm um ponto de partida único e se dividem em três gerações. A primeira geração foi treinada em sistemas legados, como mainframes; a segunda passou por treinamento em Java e linguagens semelhantes; e a terceira, mais nova geração, está aprendendo codificação diretamente com ferramentas de IA. É esta terceira geração que o preocupa, pois, segundo ele, essas pessoas podem perder completamente o pensamento lógico e sistêmico.
Ele refutou que o que é transmitido de um avanço tecnológico para outro não é o domínio de alguma ferramenta específica, mas sim a capacidade fundamental de resolver problemas. Portanto, na opinião de George, apenas saber fazer prompts corretos para o sistema de IA não é suficiente. Ele ilustrou isso com um exemplo de entrevista para arquiteto de IA: após executar com confiança um prompt complexo, o candidato não conseguiu explicar o que acontece «por trás das cenas» do sistema. Para George, a diferença entre gerenciar uma ferramenta e entender seus princípios distingue um verdadeiro engenheiro de IA de um desenvolvedor que apenas aprendeu a usar bem a IA. Saber codificar ou criar um aplicativo com IA não é o mesmo que ser um engenheiro de IA.
Em relação a habilidades específicas, George definiu cinco áreas que, segundo suas previsões, serão as mais importantes. A primeira é a própria engenharia de IA, que exige conhecimento combinado de aspectos de produto, processo, negócios e técnicos, e não apenas habilidades técnicas. A segunda é a engenharia de configuração de IA, que consiste em adaptar modelos de linguagem grandes às necessidades específicas da organização. A terceira é a infraestrutura de IA, ou seja, os sistemas em que esses modelos operam. Além disso, ele acrescentou que governança, risco e conformidade (governance, risk, and compliance), bem como cibersegurança, estão ganhando força rapidamente com a expansão do uso de IA nos GCCs e ocuparão uma parcela crescente nas contratações.
Em conclusão, George alertou sobre a contratação de nível júnior. Como as tarefas rotineiras estão se tornando cada vez mais automatizadas, ele calculou que apenas cerca de 30% dos graduados em engenharia provavelmente terão posições fortes nos GCCs em um futuro próximo, e os demais precisarão de preparação significativamente mais rigorosa, que deve começar muito antes do primeiro emprego, para que possam competir.
