EB-2 NIW para profissionais indianos de TI e engenharia

Por que profissionais indianos de TI e engenharia enfrentam um cenário de arquivamento distinto

A legislação de imigração limita o número de green cards emitidos a nativos de qualquer país a 7% do total da alocação anual baseada em emprego, independentemente da proporção de pedidos que esse país efetivamente apresenta. Como profissionais nascidos na Índia respondem por uma parcela desproporcional das petições EB-2 em relação a esse teto de 7%, a demanda na categoria EB-2 Índia costuma superar a oferta, gerando um backlog (fila de espera) medido em anos, não em meses. Esse backlog é acompanhado por meio de uma "final action date" (data de corte final) — o limite publicado mensalmente que determina de quem a priority date (a data em que o USCIS recebeu a petição correspondente) já está corrente o suficiente para avançar para a próxima etapa do visto.

O que isso afeta e o que não afeta

O teto por país determina quando um peticionário já aprovado pode apresentar o Form I-485 (ajuste de status) ou seguir para o processamento consular — isso não tem nenhuma relação com a aprovação do Form I-140 em si. O USCIS avalia o I-140 com base no mesmo padrão Dhanasar para todos os peticionários, independentemente do país de nascimento. Uma petição bem documentada apresentada por um engenheiro nascido na Índia é avaliada pelos mesmos critérios aplicados a um peticionário de qualquer outro país.

Item de ação

Antes de protocolar a petição, consulte o Visa Bulletin atual em travel.state.gov e localize a linha EB-2 na coluna referente à Índia para verificar a final action date. Reconsulte esse dado mensalmente caso você já tenha uma priority date em andamento, já que ele afeta o planejamento de prazos, não o conteúdo substantivo do que você apresenta junto ao I-140.

Traduzindo uma carreira técnica para os três prongs de Dhanasar

O teste Dhanasar (o padrão usado pelo USCIS para avaliar o NIW) faz três perguntas distintas, e um cargo técnico precisa ser traduzido para cada uma delas separadamente — um título de cargo, sozinho, não responde a nenhuma.

Prong 1: mérito substancial e importância nacional

Descreva o endeavor (o empreendimento proposto), não o cargo. "Melhorar a resiliência da infraestrutura de nuvem para clientes do setor financeiro" aponta para importância nacional; "Senior SRE na [empresa]" não aponta. Da mesma forma, trabalho em cadeia de suprimentos de semicondutores pode ser enquadrado em torno da capacidade doméstica de fabricação de chips, trabalho em segurança cibernética em torno da proteção de setores de infraestrutura crítica (energia, saúde, finanças), e implantação de modelos de IA em torno de segurança, confiabilidade ou efeitos de produtividade em escala setorial.

Prong 2: bem posicionado para promover o empreendimento

É aqui que entram credenciais, histórico e resultados mensuráveis anteriores — diplomas, patentes, publicações, implantações passadas que tiveram sucesso em escala.

Prong 3: benefício de dispensar a oferta de emprego

Explique por que exigir uma certificação trabalhista (labor certification) de um empregador específico prejudicaria o empreendimento — por exemplo, trabalho que abrange múltiplos empregadores, contribuições open-source, ou pesquisa independente que nenhuma oferta de emprego isolada consegue captar.

Redigindo a declaração do empreendimento

Escreva um parágrafo, separado de qualquer descrição de cargo, apresentando o empreendimento em termos de resultados e nomeando quem se beneficia além do empregador — um setor da indústria, um segmento de usuários, um objetivo regulatório ou de segurança, ou o público em geral. Evite métricas internas como promoções ou avaliações de desempenho; use efeitos visíveis fora da empresa.

Categorias de evidência específicas para funções de software, hardware e engenharia de sistemas

Evidência de domínio público

• Contribuições em código aberto: exporte as estatísticas do perfil no GitHub/GitLab (gráfico de contribuições, stars, forks, pull requests mesclados) e inclua repositórios nos quais o peticionário atue como mantenedor ou principal contribuidor. Tire um print da linha do tempo de contribuições com as datas visíveis.
• Patentes: obtenha os PDFs diretamente do USPTO Patent Public Search (banco de busca de patentes do órgão de patentes dos EUA) ou do escritório de patentes estrangeiro correspondente (por exemplo, o portal IP India, no caso da Índia); inclua a patente concedida, e não apenas o pedido, sempre que possível.
• Publicações e citações: liste artigos publicados em periódicos ou conferências do IEEE/ACM com os links de DOI, e gere um relatório de citações do Google Scholar mostrando o número de citações e o índice h no momento do protocolo.
• Palestras e participação em normas técnicas: programações de conferências, gravações de palestras ou atas de reuniões de comitês de normalização que mostrem a participação nominal do peticionário.
• Graus de associação profissional: cartas de elevação a IEEE Senior Member ou categoria equivalente, que documentam uma avaliação independente por pares.

Evidência interna, mantida pelo empregador

Documentos de arquitetura de sistemas, relatórios de pós-incidente ("postmortems") e benchmarks de desempenho raramente saem da empresa. Para utilizá-los:

1. Identifique o resultado mensurável específico (melhoria de uptime, redução de latência, economia de custos, ganhos de throughput).
2. Peça a um supervisor ou líder técnico que escreva uma carta quantificando esse resultado e indicando o alcance da implementação (número de usuários, sistemas ou regiões afetadas).
3. Anexe uma versão com dados sensíveis ocultos ("redacted") do documento original como exhibit de apoio, sempre que a confidencialidade permitir, com referência cruzada feita na carta.

Alegações quantificadas e atribuíveis a uma pessoa específica pesam mais do que descrições de funções genéricas.

Montando o conjunto de cartas de recomendação: a quem pedir e o que especificar

Petições nesse perfil costumam incluir várias cartas, tipicamente uma combinação de supervisores diretos, colaboradores multifuncionais (gerentes de produto, arquitetos de equipes adjacentes) e especialistas independentes — professores, membros de comitês de normas técnicas (standards-body) ou engenheiros de outras empresas que nunca trabalharam diretamente com o peticionário. O grupo independente importa porque demonstra reconhecimento além da própria cadeia hierárquica do peticionário.

O que cada carta precisa declarar

1. As credenciais e o papel do próprio autor da carta — cargo, anos de atuação na área, e por que está em posição de avaliar esse trabalho.
2. Como ele conhece o trabalho do peticionário — supervisão direta, revisão de código, participação conjunta em comitê de normas técnicas, citação de pesquisa publicada, coparticipação em conferências.
3. Afirmações específicas e quantificadas, vinculadas à declaração do empreendimento (endeavor statement): sistemas que processam um volume determinado de requisições, reduções de latência em uma porcentagem indicada, as reivindicações (claims) de uma patente e como foram utilizadas, o número de citações de um artigo. Evite adjetivos como "brilhante" ou "excepcional" isolados — associe cada afirmação a um número, ao nome de um sistema ou a um evento datado.

Evitando a armadilha do modelo padronizado

Redija um esboço de fatos separado para cada carta, em vez de enviar uma única carta-modelo para todos os recomendadores apenas assinarem. Os avaliadores devem escrever com a própria voz, usando sua própria estrutura de frases e vocabulário. Os oficiais comparam as cartas dentro de uma mesma petição, e frases quase idênticas, ordem de parágrafos repetida ou expressões incomuns que se repetem entre recomendadores supostamente independentes constituem um gatilho reconhecido de RFE (Request for Evidence, pedido de evidências adicionais).

Montando a declaração pessoal e alinhando-a ao Form I-140 e aos dados de mercado de trabalho no estilo ETA-9089

Estrutura da declaração

Escreva a declaração pessoal como um arco narrativo, não como um currículo em forma de prosa: (1) origem do foco técnico, (2) problema ou lacuna específica na área, (3) a contribuição do peticionário, (4) evidências de que essa contribuição ultrapassa um único empregador, (5) plano voltado ao futuro, amarrado à declaração de empreendimento (endeavor statement) já redigida anteriormente. Cada seção deve remeter a exhibits específicos, por número, para que o leitor (o oficial) possa verificar as afirmações sem precisar procurar.

Usando dados de mercado de trabalho sem certificação laboral

Uma petição de NIW dispensa o processo de PERM, portanto não há ETA-9089 a apresentar — mas o contexto de mercado de trabalho que o PERM documentaria ainda pode sustentar o critério de importância nacional. Cite o código O*NET-SOC correspondente à ocupação (por exemplo, 15-1252.00 para Software Developers, 17-2199.xx ou 15-1299.xx para diversas funções de sistemas/engenharia) e faça referência a dados do Department of Labor sobre projeções de emprego ou níveis de salário prevalecente (prevailing wage) para esse código. Use isso para descrever a escala e a demanda da área, não para argumentar elegibilidade pessoal a um determinado nível salarial.

Onde encontrar códigos e dados atualizados

Consulte os códigos O*NET-SOC e suas descrições atuais em onetonline.org. Para números de salário prevalecente e perspectivas ocupacionais, use o Foreign Labor Certification Data Center do Department of Labor (flcdatacenter.com) e o Occupational Outlook Handbook do Bureau of Labor Statistics — ambos são atualizados periodicamente, então busque a versão vigente no momento do protocolo, em vez de confiar em números já salvos anteriormente.

Organizando o índice de exhibits e o pacote de submissão

Um índice de exhibits (exhibit index) é o documento único que permite a um oficial localizar cada peça de evidência sem precisar vasculhar centenas de páginas. Petitioners que pulam essa etapa, ou que enterram exhibits dentro de PDFs longos e sem identificação, forçam o adjudicador a procurar — e evidência que não pode ser encontrada rapidamente é, na prática, evidência que não existe para efeitos de uma revisão ágil.

Por que a estrutura importa especificamente aqui

Petições baseadas no padrão Dhanasar dependem de evidências extraídas de muitas fontes diferentes: repositórios de código, depósitos de patentes, artigos de conferência, memorandos internos e cartas. Como essas evidências não chegam em um formato uniforme, cabe ao petitioner impor ordem sobre elas. Um revisor deve conseguir abrir o índice, ver qual prong (critério) um determinado exhibit sustenta, e ir direto à página correta.

Defina a lógica do pacote antes de montar as páginas

Antes de imprimir ou combinar PDFs, decida:

1. Um esquema estável de numeração ou lettering de exhibits que não precisará mudar depois que as cartas forem redigidas.
2. Qual prong (ou prongs) cada exhibit deve sustentar.
3. Quais documentos exigem tradução certificada antes de poderem ser incluídos.
4. Onde evidências duplicadas (por exemplo, uma patente citada tanto em uma carta quanto em seu próprio exhibit) serão referenciadas cruzadamente em vez de reproduzidas.

A próxima seção detalha isso com uma tabela concreta e uma convenção de nomeação de arquivos.

Organizando o índice de provas e o pacote de submissão

Monte primeiro o índice de provas

Elabore o índice antes de digitalizar qualquer documento. Ele se torna o mapa que o oficial usa para percorrer o pacote, e obriga você a identificar lacunas na sua própria evidência.

Nomenclatura dos arquivos

Adote um padrão consistente: Exhibit_A_Patent_US1234567.pdf, Exhibit_B_Letter_Iyer.pdf. Evite nomes genéricos como scan001.pdf — tanto o revisor quanto você perdem tempo tentando reconciliar esses arquivos com o índice.

Ordem de montagem

1. Carta de apresentação (cover letter) resumindo a petição e listando os exhibits
2. Formulário I-140
3. Exhibits de evidência, na ordem do índice
4. Declaração pessoal (personal statement)
5. Cartas de recomendação
6. Traduções e certificações de quaisquer documentos emitidos na Índia (diplomas, cartas de experiência profissional), cada tradução acompanhada da certificação do tradutor quanto à precisão e competência, conforme as instruções atuais do USCIS — confirme os requisitos em uscis.gov antes de protocolar.

Gatilhos comuns de RFE para este perfil de peticionário e como preveni-los

Um pequeno conjunto de problemas recorrentes responde pela maioria dos RFEs (Request for Evidence, pedido de evidências adicionais) emitidos para este perfil.

Genericidade

Uma declaração pessoal que poderia pertencer a qualquer engenheiro de software ou de hardware — sem tecnologia nomeada, sem implantação específica, sem resultado mensurável — soa intercambiável. Cada afirmação deve remeter a um projeto, sistema ou publicação específicos, também presentes no índice de exhibits (evidências documentais).

Cartas só com adjetivos

Cartas que descrevem o peticionário como "brilhante", "excepcional" ou "peça-chave" sem nenhum número associado (usuários atendidos, latência reduzida, sistemas implantados, artigos citados) atraem escrutínio. Cada carta deve conter pelo menos uma afirmação quantificada e verificável.

Certificações de tradução ausentes

Históricos escolares, diplomas e declarações de experiência profissional emitidos na Índia e submetidos em tradução para o inglês sem a certificação do tradutor quanto à precisão e à competência são uma causa frequente e inteiramente evitável de RFE. Confirme que todo documento traduzido traz uma página de certificação assinada.```

Evidência independente escassa

Um dossiê construído quase inteiramente com cartas fornecidas pelo empregador e documentos internos, sem citações, patentes, avaliadores independentes ou reconhecimento profissional externo à cadeia de subordinação do peticionário, levanta questionamentos sobre se o registro reflete o padrão individual do peticionário.

Confundir o sucesso da empresa com o papel individual

Evidências que descrevem a receita, a participação de mercado ou a adoção de produtos do empregador sem isolar a contribuição específica do peticionário deixam o papel individual pouco claro.

Verificação final

Antes de protocolar, percorra o índice de exhibits critério por critério (prong por prong) e confirme que cada um dos três critérios de Dhanasar está sustentado por mais de um tipo de evidência independente.