Uma equipe de Tl de uma Secretaria da Fazenda mantém o sistema de emissão de guias de arrecadação em um repositório Git central, usando a branch main diretamente em produção. Um commit já publicado alterou o calculo de ISS e gerou valores incorretos. A auditoria exige que o histórico da main permaneça integro, sem reescrita de histórico já publicado, e que a correção seja aplicada a partir do commit problemático. Considerando as recomendações usuais para desfazer mudanças em uma branch publica já compartilhada, o procedimento que esta alinhado a essas exigências é, na branch main, executar

Uma Secretaria da Fazenda estadual expõe, em ASP.NET Core (.NET 8, Minimal APIs), uma API para calculo de ICMS sobre fretes interestaduais. O serviço ICalculoTributoService utiliza FazendabDbContext (EF Core) para persistência e um cliente HTTP para consultar tabelas de alíquotas interestaduais via serviço externo. Em testes de carga, o uso de FazendaDbContext e ICalculoTributoService como Singleton gerou aumento de memória e conexões abertas ao banco. Considerando o modelo de injeção de dependência e lifetimes do contêiner padrão do .NET, a combinação de lifetimes que é tecnicamente adequada para esse cenário é registrar FazendaDbContext. como

Um Tribunal de Contas do Estado (TCE) solicita a uma SEFAZ acesso a dados de contribuintes constantes dos sistemas informatizados, visando a auditar benefícios fiscais setoriais. Segundo a Resolução SF n220/2012, com redação dada pela Resolução SFP nº 42/2020, o procedimento compatível com o regime de sigilo fiscal e com a disciplina especifica de compartilhamento com o TCE é

Uma Secretaria da Fazenda estadual pretende usar um sistema de IA para ranquear contribuintes por risco de sonegação, priorizando autos de infração e fiscalizações. A equipe jurídica alerta que diretrizes de governança em IA enfatizam transparência, explicabilidade e prestação de contas nas decisões automatizadas. Em termos de desenho do sistema e de governança, a medida mais adequada para alinhar o ranqueador de risco fiscal a esses princípios é

A área de Analytics de uma Secretaria da Fazenda mantém múltiplos modelos em produção (inadimplência, fraude em NF-e, seleção para auditoria, previsão de arrecadação) e precisa garantir um ponto Único de verdade sobre qual versão de cada modelo está em produção, permitir a promoção controlada de modelos de staging para produção com critérios formais e aprovações, e manter histérico versionado com metadados (métricas, features, autor, datas) disponível para auditorias. O componente de uma arquitetura de MLOps que atende diretamente a esses requisitos é um

Uma equipe de auditoria possui uma tabela de NF-e com mais de 1 bilhão de registros em um pyspark.sgl.DataFrame chamado df. A auditora deseja inspecionar apenas 1.000 registros localmente em seu notebook, usando funcionalidades avangadas de pandas para buscar inconsisténcias. Nesse cenário, a abordagem em PySpark mais apropriada para gerar esses registros em um pandas. DataFrame, minimizando o risco de estouro de memória no ambiente local é:

Uma Secretaria da Fazenda pretende, ao mesmo tempo:

I. prever o valor de arrecadação mensal de ICMS para os próximos meses;
II. classificar cada declaração de contribuinte em “alto risco” ou “baixo risco” para fins de seleção de auditoria.

Considerando os tipos de modelos de aprendizado de maquina, a combinação de tarefas que está conceitualmente alinhada com esses objetivos é:

Uma base tributaria de uma SEFAZ é analisada por meio de um cubo OLAP de arrecadação de ISS, com as seguintes dimensões: Ano, Município, Atividade econômica, Regime tributário e Contribuinte. Em uma reunido, um analista parte de uma visão agregada da arrecadação anual por município, em seguida, navega para uma visão mensal e depois para uma visão por contribuinte dentro de um município especifico, mantendo as demais dimensões fixas. Do ponto de vista conceitual em OLAP, essa sequência de operações é um exemplo de

Uma Secretaria da Fazenda estadual recebeu dados de todos os lançamentos de ICMS dos últimos 5 anos (valores, setores econômicos, municípios, regime tributário e situação do contribuinte). Antes de construir modelos preditivos de risco ou definir novas regras de fiscalização, a equipe decide realizar apenas uma etapa sistemática de resumo, visualização e detecção de padrões e outliers nos dados, sem ainda formular hipóteses formais ou treinar modelos. Esse trabalho inicial é caracterizado como

Uma base tributaria de uma SEFAZ possui duas tabelas:
contribuinte (id, cpf_cnpj, nome, situacao) debitos (id, contribuinte_id, valor, tipo_tributo, data_vencimento)
A equipe de Banco de Dados deseja listar contribuintes ativos, exibindo o nome e o valor total de débitos vencidos, considerando apenas tributos do tipo IPTU (isto €, data vencimento anterior à data atual). Considerando consultas escritas em um SGBD em que não ha mais de um contribuinte com o mesmo nome na base de dados e em que CURRENT_DATE retorna a data atual, a consulta SQL que atende ao requisito é: