Uma edição local não equivale a uma preservação comprovada
Alterar um fundo, remover um objeto ou ampliar um enquadramento parece uma operação delimitada. No entanto, os sistemas generativos produzem uma nova saída a partir da imagem, da instrução e, quando existe, de uma máscara ou referência. O facto de o resultado ser visualmente apelativo não demonstra que o modelo tenha preservado sem alterações aquilo que não lhe foi pedido para modificar.
Esta nuance é especialmente importante no comércio eletrónico, na publicação editorial, no design de produto e na comunicação de marca. Uma edição de fundo pode introduzir diferenças na cor de um produto, redesenhar texto numa embalagem, alterar um logótipo, mudar a forma de uma mão ou modificar um rosto. Noutros casos, pode deslocar elementos da composição, variar sombras relevantes ou substituir detalhes documentais por conteúdo plausível, mas incorreto.
A documentação da API de imagens da OpenAI indica que uma máscara orienta o processo de edição, mas adverte que a sua forma pode não ser seguida com precisão. Esta capacidade documentada deve ser interpretada como um controlo de intenção, e não como uma garantia de que todos os píxeis fora da zona assinalada permanecerão idênticos. Por isso, o controlo de qualidade deve avaliar duas questões distintas: se ocorreu a alteração autorizada e se as partes protegidas foram preservadas.
A edição localizada deve ser encarada como um problema de aceitação, e não como uma demonstração de criatividade. Antes de gerar uma saída, a equipa define quais são os limites da operação e de que evidência necessita para a aprovar. Se não conseguir definir o que deve ser conservado, também não conseguirá verificar de forma consistente que foi preservado.
Esta abordagem aplica-se tanto a fluxos com ferramentas de desktop como a integrações por API. É também independente do fornecedor: pode ser usada ao avaliar uma operação com modelos como GPT Image 2.5 Sunburst, Nano Banana 2 ou Stable Diffusion 3.5 Large, desde que sejam documentadas as capacidades reais do canal de acesso utilizado e cada fluxo seja testado com ativos representativos.
Definir o contrato de edição antes de gerar
O contrato de edição é uma ficha breve e versionada que converte um pedido criativo em condições verificáveis. Deve acompanhar cada caso de teste e cada ativo publicado. A sua função é evitar critérios variáveis depois de se ver uma variante favorável e permitir que outra pessoa reproduza a decisão de aprovação ou rejeição.
O primeiro componente é a alteração permitida. Deve descrever a operação concreta, a sua localização, a direção da alteração e os seus limites. «Melhorar a imagem» não é uma instrução verificável; «substituir o fundo cinzento por um fundo branco uniforme sem modificar o produto nem a sua sombra de contacto» permite, sim, conceber controlos. Quando o resultado esperado admitir várias soluções visuais, convém definir o intervalo aceitável em vez de exigir uma correspondência estética exata.
O segundo componente são as regiões protegidas. Podem ser píxeis, uma área delimitada, objetos detetáveis ou áreas semânticas: produto, etiqueta, título, rosto, mãos, documento, logótipo, preço ou texto legal. É preferível separar as regiões que devem permanecer visualmente idênticas daquelas que podem sofrer pequenas variações toleráveis, como uma textura de fundo que será conservada, mas não é considerada crítica.
O terceiro componente são os atributos invariantes. Nem sempre basta proteger uma região inteira. Um produto pode admitir a remoção de pó, mas não alterações à sua silhueta, cor, tamanho relativo, número de botões, etiqueta ou geometria. Um retrato pode exigir a preservação da identidade aparente, da expressão, da direção do olhar ou de traços documentais. Uma peça editorial pode proteger a legibilidade e a literalidade de um letreiro, embora seja permitido modificar o ambiente.
Por fim, o contrato deve incluir tolerâncias e motivos de rejeição. A tolerância é definida pelo risco e pela finalidade, não por um valor universal. Um fundo decorativo pode admitir uma diferença percetiva maior do que o preço de um produto. Deve ficar explícito quem tem autoridade para alterar o limiar: por exemplo, a pessoa responsável pelo catálogo, a área jurídica ou a direção editorial, consoante o tipo de ativo.
Campos mínimos do contrato de edição
| Campo | Pergunta a que responde | Exemplo de critério |
|---|---|---|
| Ativo de origem identificado | Sobre que original se trabalha? | Identificador interno, versão e estado dos direitos revisto |
| Alteração permitida | O que deve mudar? | Substituir apenas o fundo fora do contorno do produto |
| Regiões protegidas | Que zonas não podem ser alteradas? | Produto, etiqueta, preço, logótipo e sombra de contacto |
| Atributos invariantes | Que propriedades devem ser mantidas? | Texto literal, geometria, cor aprovada e proporção |
| Tolerância | Que variação seria aceitável? | Nenhuma diferença no texto; revisão visual da cor |
| Rejeição | O que invalida a saída? | Texto ilegível, alteração da etiqueta, rosto alterado ou margem defeituosa |
Classificar a operação para atribuir controlos proporcionais
Nem todas as edições têm o mesmo risco. Classificá-las evita aplicar um único controlo superficial a operações heterogéneas. A classificação deve refletir tanto a zona modificada como a sensibilidade daquilo que se protege. Uma substituição de fundo numa imagem decorativa não tem o mesmo perfil que a mesma operação sobre uma fotografia de um medicamento, de uma pessoa identificável ou de um produto com informação regulamentar.
As edições de fundo e a limpeza de objetos costumam ser candidatas a automatização limitada quando o primeiro plano é simples, está bem delimitado e não contém texto ou atributos críticos. Ainda assim, devem ser verificados contornos, sombras, reflexos, recortes e possíveis alterações ao objeto principal. As operações de ampliação de enquadramento exigem prudência adicional: a área acrescentada é necessariamente gerada e não constitui prova de um contexto histórico ou documental que não estava presente no original.
As edições de produto, texto incorporado, preços, etiquetas, rostos e mãos devem ser tratadas como categorias de alto risco. O problema não é apenas poderem conter falhas visíveis. Uma variante pode parecer correta numa revisão rápida e, ainda assim, alterar uma letra, uma quantidade, uma proporção ou uma característica de identidade. Nestes casos, a automatização pode servir para propor variantes, mas a publicação deve depender de controlos específicos e, habitualmente, de uma revisão humana competente.
A documentação da Adobe sobre Generative Fill descreve uma seleção manual com pincel, com ajuste de tamanho e dureza, para adicionar ou substituir conteúdo a partir de uma instrução. Também contempla o uso opcional de uma imagem de referência. A documentação do Photoshop descreve o uso de referências numa seleção ativa para substituir uma zona ou colocar um objeto mantendo o fundo. Estes controlos são úteis para preparar uma operação, mas a organização deve verificar por conta própria se o resultado cumpre o seu contrato de preservação.
Matriz inicial de decisão por tipo de edição
| Operação | Risco dominante | Destino recomendado | Controlo mínimo |
|---|---|---|---|
| Fundo sem texto nem produto sensível | Recorte, contornos e cor | Automatizável com amostragem | Comparação do primeiro plano e revisão dos contornos |
| Remover objeto secundário | Reconstrução incorreta do ambiente | Proposta ou automatização limitada | Revisão da continuidade visual e dos elementos vizinhos |
| Ampliar enquadramento | Contexto inventado | Revisão humana | Identificar área acrescentada e proibir uso documental |
| Produto com etiqueta ou embalagem | Texto, geometria e cor | Proposta com aprovação obrigatória | OCR, comparação de atributos e revisão especializada |
| Preço, texto legal ou documento | Alteração literal ou regulamentar | Fora do fluxo generativo de publicação | Edição determinística e validação do conteúdo |
| Rosto identificável ou mãos | Identidade, anatomia e consentimento | Proposta com aprovação obrigatória | Revisão humana e política específica de utilização |
Preparar um caso de teste reproduzível
Um caso de teste não começa com o prompt. Começa com um original estável e identificado. Conserve o ficheiro de origem, a sua versão, a data de receção ou criação, o contexto de utilização previsto e a decisão aplicável sobre direitos ou licenças. A avaliação técnica não resolve por si só a autorização para modificar, reutilizar ou publicar o ativo; essa decisão deve ser gerida no fluxo adequado.
Versione a instrução completa, e não apenas uma frase resumida. Registe o modelo, a versão disponível, o canal ou ferramenta, os parâmetros expostos, as imagens de referência, a máscara ou seleção e o número de variantes solicitadas. Se a ferramenta não expuser algum destes elementos, registe essa ausência. Não se deve presumir que uma capacidade observada noutra interface esteja disponível, nem que o mesmo nome de modelo implique resultados idênticos entre produtos ou versões.
Prepare igualmente uma expectativa observável. Pode consistir numa máscara esperada, numa descrição da zona que deve mudar, numa lista de invariantes e em exemplos de saídas que seriam rejeitadas. Para uma edição de fundo, assinale que parte do produto será comparada. Para uma modificação de objeto, defina que relações espaciais devem ser mantidas. Para um letreiro, preserve a transcrição aprovada com a qual o resultado será confrontado.
Os testes devem incluir casos normais e casos adversos. Entre estes últimos, convém incluir margens finas, transparências, reflexos, cabelo, texto pequeno, etiquetas curvas, produtos brilhantes, mãos sobrepostas e fundos de cor semelhante à do objeto. O objetivo não é obter uma classificação geral do modelo, mas descobrir quando o fluxo deixa de ser fiável para a utilização concreta.
O trabalho de investigação sobre MagicBrush apresenta um conjunto de dados anotado manualmente para edição orientada por instruções, com situações de uma e várias interações, com e sem máscara, e com avaliação quantitativa, qualitativa e humana. O seu âmbito não certifica um produto nem estabelece limiares universais para uma organização, mas sustenta a ideia de que a avaliação da edição por instruções é multidimensional e não se reduz a uma única impressão visual.
Processo de preparação do caso
- 01Identificar e congelar o ativo de origem; conservar uma cópia que não entre no processo generativo.
- 02Escrever o contrato de edição, com alteração permitida, zonas protegidas, invariantes e motivos de rejeição.
- 03Criar máscara, seleção ou referência quando o fluxo o permitir; registar como foi construída.
- 04Versionar o prompt, a ferramenta, o modelo, os parâmetros visíveis e o número de variantes.
- 05Definir as medições automáticas e o tipo de revisão humana antes de gerar.
- 06Gerar variantes sem substituir o original e associar cada saída ao caso de teste.
Medir separadamente o cumprimento e a preservação
A avaliação deve ter dois resultados independentes. O primeiro é o cumprimento da instrução: o objeto foi removido, o fundo foi substituído, o elemento solicitado foi acrescentado na região prevista? O segundo é a preservação: as regiões e os atributos fora da permissão permanecem aceitavelmente iguais? Uma saída pode passar no primeiro teste e falhar no segundo.
A comparação por píxel ou por região pode ser útil para detetar alterações inesperadas quando as imagens estão alinhadas e a operação pretende deixar uma zona intacta. Contudo, não deve ser interpretada como um teste completo de identidade semântica. Pequenas diferenças de compressão ou renderização podem gerar alertas, enquanto uma alteração significativa para o negócio pode afetar uma zona pequena e passar despercebida numa métrica global.
Por isso, combine várias verificações. Uma máscara de exclusão permite calcular diferenças fora da área autorizada. O OCR permite comparar o texto detetado com uma transcrição de referência, mas deve tratar resultados duvidosos como um sinal para revisão, e não como uma aprovação automática. A comparação geométrica pode verificar contornos, relações espaciais ou dimensões relativas de um produto. Métodos de semelhança visual ou embeddings podem ajudar a priorizar variantes anómalas, mas não provam por si só a preservação de atributos regulamentados, textuais ou de identidade.
Os limiares devem ser calibrados com um conjunto de exemplos etiquetados por revisores. Meça, no mínimo, falsos aprovados, falsas rejeições e desacordos entre revisores por categoria. Um falso aprovado —aceitar uma imagem que viola um invariante— costuma ter um custo superior em ativos sensíveis. A taxa aceitável não pode ser deduzida da documentação de uma ferramenta: depende do risco, do canal de publicação e da governação de quem publica.
Não utilize a ausência de alertas automáticos como prova conclusiva. Um alerta deve abrir uma revisão; uma métrica favorável só pode automatizar uma decisão se o contrato, o histórico de testes e o nível de risco justificarem explicitamente essa delegação.
Aplicar controlos especializados a texto, marcas, pessoas e produtos
O texto incorporado merece um tratamento separado. Devem ser verificadas a sua legibilidade, literalidade e, quando aplicável, a integridade do idioma, moeda, unidades, avisos e dados de contacto. Se a imagem contiver preços, informação legal, dados clínicos, instruções de segurança ou um documento, o fluxo generativo não deve ser o mecanismo que decide o conteúdo final. Uma edição aparentemente cosmética pode modificar caracteres e alterar o significado.
Os logótipos e as marcas exigem verificar tanto a forma como o contexto de utilização. Uma ferramenta pode redesenhar uma marca com variações subtis, apagar uma atribuição ou introduzir sinais de terceiros. A validação visual não substitui a revisão das permissões aplicáveis ao ativo de origem, à referência e ao destino de publicação. A proveniência técnica também não concede direitos de utilização.
Em rostos identificáveis, a revisão deve verificar identidade aparente, traços, expressão, olhar, pele, cabelo e contexto. Deve também ser aplicada a política de consentimento e direitos de imagem da organização. Nas mãos, devem ser avaliados anatomia, dedos, contacto com objetos e continuidade de acessórios. Estes controlos são qualitativos e sensíveis à finalidade; não convém fingir que uma métrica única os resolve.
Para produtos, convém criar uma ficha de atributos críticos por família: contorno, número de componentes, material, cor aprovada, etiqueta, embalagem, orientação, tamanho relativo e acessórios. A comparação deve ser feita com uma referência de produto autorizada, e não com a memória do revisor. Quando uma referência for utilizada para ajudar a geração, continue a tratá-la como uma entrada sujeita a direitos, restrições e registo.
A documentação da Adobe sobre referências indica utilizações orientadas para substituir uma zona selecionada ou colocar um objeto conservando o fundo. É uma capacidade de composição que pode ser útil para conceber testes, mas não demonstra que o objeto produzido coincida com um catálogo, uma especificação técnica ou uma identidade de marca.
Revisão humana proporcional ao risco
- 01Atribuir risco baixo, risco médio ou risco elevado consoante a categoria do ativo e o destino de publicação.
- 02Permitir amostragem apenas em categorias com contrato estável, testes históricos suficientes e consequências limitadas.
- 03Exigir aprovação individual para produtos, rostos, marcas, texto relevante e conteúdo editorial ou documental.
- 04Separar, quando possível, quem gera a variante de quem aprova a publicação.
- 05Encaminhar os casos ambíguos para a pessoa responsável por conteúdo, marca, jurídico ou produto; não converter a incerteza em aprovação tácita.
Conservar variantes e evidência de proveniência sem a confundir com garantia de qualidade
A geração pode ser não determinística: com o mesmo pedido podem surgir saídas diferentes e uma variante aprovada pode não se repetir exatamente depois de uma atualização de ferramenta. Por isso, cada saída deve manter uma relação explícita com o original, o caso de teste e a decisão tomada. Não substitua o ativo de origem nem troque uma variante aprovada por outra de aparência semelhante sem repetir a validação.
O registo mínimo deve incluir o identificador do ativo de origem, identificadores das entradas de referência, o contrato de edição, o prompt, a máscara ou seleção, a ferramenta e versão declarada, os parâmetros disponíveis, a data de geração, as variantes produzidas, os resultados dos controlos, a identidade ou função do revisor, a decisão, o motivo de rejeição se existir e o destino de publicação. A conservação de variantes rejeitadas ajuda a investigar falhas, desde que a sua retenção cumpra as regras internas de privacidade e conservação.
A C2PA define uma especificação técnica de proveniência com manifestos, ingredientes e ações, e inclui mecanismos para declarar se foram incluídas todas as ações. Pode ser utilizada para exprimir relações entre um ativo e os seus derivados ou entre uma edição e certas ações registadas. No entanto, a sua presença não demonstra por si só que a zona não editada conserva os mesmos píxeis, que um texto está correto ou que uma saída cumpre uma política de publicação. A evidência de proveniência e a validação de qualidade são controlos complementares.
Antes de publicar, relacione o destino concreto com a aprovação. Uma imagem adequada para uma maquete interna pode não ser adequada para um catálogo, uma campanha ou um arquivo editorial. A decisão deve indicar para que canal e âmbito foi aprovada e deve ser invalidada ou revista se mudarem o ativo, o prompt, a máscara, o modelo ou a finalidade.
Evidência que deve acompanhar uma saída aprovada
| Grupo | Evidência | Finalidade |
|---|---|---|
| Origem | Ativo de origem e referências identificadas | Relacionar a saída com as suas entradas |
| Instrução | Contrato, prompt e versão | Explicar a alteração autorizada |
| Execução | Ferramenta, modelo declarado, parâmetros e máscara | Reproduzir ou investigar o procedimento |
| Validação | Resultados de métricas, OCR e revisão | Justificar a decisão de qualidade |
| Aprovação | Revisor, data, âmbito e destino | Delimitar quem autorizou que utilização |
| Proveniência | Manifesto ou registo compatível, quando existir | Conservar relações e ações declaradas |
Política final: automatizar, propor ou bloquear
A decisão final deve ser explícita e passível de revisão. Automatizar não significa que uma categoria nunca seja inspecionada; significa que, sob condições definidas, pode ser aprovada através de controlos instrumentados e amostragem. Propor significa que o sistema pode produzir candidatos, mas não publicar sem uma pessoa autorizada. Bloquear significa que a organização decidiu não utilizar geração para essa alteração ou esse tipo de ativo no canal em causa.
Uma política prudente começa com um âmbito reduzido. Selecione operações de baixo risco, crie casos de teste representativos, reveja todas as saídas durante um período inicial e registe as falhas. Só depois de observar resultados estáveis e de acordar limiares se deve considerar a amostragem. Se o modelo, a interface, a configuração ou o tipo de ativo mudarem, volte a avaliar: o desempenho observado num fluxo não deve ser extrapolado automaticamente para outro.
Este guia não permite concluir que um fornecedor, modelo ou modalidade garanta preservação perfeita. As fontes disponíveis descrevem controlos de seleção, máscara, referência e proveniência, bem como a complexidade de avaliar edição orientada por instruções. A fiabilidade operacional para um caso concreto deve ser demonstrada com testes próprios, critérios de rejeição e governação adequada.
O resultado desejável não é uma aparência impecável numa demonstração isolada. É uma decisão defensável: a equipa consegue mostrar que alteração autorizou, o que protegeu, que controlos executou, que incertezas encontrou e por que motivo uma pessoa ou um sistema aprovou, encaminhou para revisão ou rejeitou a variante.
Questões em aberto
- As capacidades efetivamente disponíveis, os parâmetros expostos e o comportamento da edição podem variar consoante o modelo, a versão e o canal de acesso; devem ser confirmados no ambiente que será utilizado.
- Não existe nas fontes fornecidas um limiar universal de diferença por píxel, semelhança visual, OCR ou taxa de falsos aprovados que seja seguro para todos os ativos e setores.
- As verificações automáticas podem detetar anomalias, mas não garantem por si só a exatidão de texto, identidade, geometria de produto, conformidade regulamentar nem adequação editorial.
- A informação de proveniência pode estar incompleta ou não incluir todas as ações; mesmo um registo completo não prova por si só que uma edição visual preserva os atributos exigidos.
- A autorização para editar e publicar depende de direitos, licenças, consentimento e políticas aplicáveis ao ativo, às referências e ao canal de distribuição; estas questões não são resolvidas pela qualidade técnica da saída.
Continue a explorar
Fontes consultadas
Correções e transparência
Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.
Propor uma correção