AI auto-tagging in DAM: governance & quality control

Why it matters

Auto-tagging promises to describe large backlogs that people will never tag by hand. The risk is that it quietly fills the metadata with values nobody checked. Search, filters, rights checks and integrations then treat those values as facts.

Evidence from public institutions shows that results vary widely by field. In the Library of Congress "Exploring Computational Description" experiments on e-book cataloguing (2022–2024), identifiers, author and title could be extracted at around 85% accuracy, while subject headings, genre and dates were accurate at or under 50% of the time R21. These figures come from library cataloguing, not from image tagging, and should not be reused as DAM benchmarks. The lesson that transfers is that subject-like fields are much harder than factual ones. The Library concluded that no tool was then good enough to run fully automatically for records that must be highly reliable, and moved on to human-in-the-loop prototypes R21.

The risks are well documented beyond accuracy:

• Bias. NIST's AI Risk Management Framework names three categories of AI bias (systemic, computational and statistical, and human-cognitive) and notes that each can occur without any intent to discriminate R1. For face recognition, NIST's 2019 vendor test found demographic differentials in the majority of the algorithms it studied, and large differences between algorithms R12.
• Invented content. Generative models used for captions, descriptions and alt text can produce "confabulation", which NIST defines as confidently stated but false content R2.
• Over-trust. The same NIST profile describes automation bias, the excessive deference of people to automated systems R2. A review step only helps if reviewers actually check.
• Legal exposure. Faces are personal data. Some uses of biometric data are regulated or prohibited (see practice 7).

On figures. No independent, freely accessible study measuring the accuracy of DAM auto-tagging across vendors was found. Vendor-published accuracy or time-saving figures are not repeated here (see the about page on sourcing).

Core concepts

Recommended practices

1. Decide where AI tags help, field by field

Why. NIST's AI Risk Management Framework, published in 2023 for voluntary use R26, asks organisations to keep an inventory of their AI systems and to map each system's context and risks before measuring and managing them R1. In a DAM, "the AI" is usually several features (image tags, OCR, transcripts, face recognition, generated descriptions), each writing to different fields. The Library of Congress results show that the same technology can be reliable for one field and unreliable for another R21.

How.

1. List every AI feature enabled or planned, the fields it writes to, and the service or model behind it.
2. Rate each target field by the cost of a wrong value. A practical scale:

3. Start with the fields where search is weakest today and errors are cheap. Leave fields that drive rights, permissions or publication to people.

2. Keep AI values recognisable: source, model, date, confidence

Why. If AI values and human values are mixed in one field without a marker, reviewers cannot tell what was checked, and you cannot clean up after a bad model run. The IPTC has already modelled this for news metadata: NewsML-G2's @why and @how attributes say whether a value was added by a person, by a person assisted by a tool, by a tool, inferred from a taxonomy, or added as an ancestor of another value; @confidence and @relevance carry scores; and metadataCreator names the person, organisation or system that created the metadata R14. W3C PROV offers a general model for the same idea R17.

How.

• Add these attributes to your data dictionary (see DAM metadata schema & governance): value source (human, import, AI-suggested, AI-accepted), AI service and model version, run date and confidence.
• Prefer separate AI fields, or a per-value source flag, to overwriting human fields. Platforms do this differently (the solution pages cited in this guide are linked under How DAM platforms support this). In the wiki: human tags and AI tags are kept separately in Acquia DAM ; records and values carry an aIInfluenced flag and field-population logs in Aprimo ; AI tags are flagged auto_generated with a source in the Brandfolder API ; and generated field text is flagged "Generated by AI" in Sitecore Content Hub .
• Check that the source information survives export, API reads and migration. If it is lost on the way out, the next system will treat AI guesses as curated metadata (see the DAM migration guide).
• Keep this apart from AI-generated content. Metadata about an asset produced by AI is a different matter from an asset created by AI, which the IPTC DigitalSourceType vocabulary and the 2025.1 properties "AI System Used" and "AI System Version Used" describe R15. See Content provenance in DAM.

3. Map AI output to your controlled vocabulary

Why. A general-purpose model returns its own labels, in its own language, at its own level of detail. Without mapping, you get a second, uncontrolled keyword list next to your controlled vocabulary, and facets split ("automobile", "car", "vehicle").

How.

• Allow-list: accept only labels that map to a term in your vocabulary. Record the mapping in a table that names the model label, your term and the type of match. W3C SKOS provides mapping properties for this: exactMatch, closeMatch, broadMatch, narrowMatch and relatedMatch R16.
• Deny-list: block labels that are wrong for your context, offensive, or that touch sensitive attributes.
• Broader terms: if the model returns a specific label and your vocabulary is coarser, map upwards. NewsML-G2 even has a value (ancestor) for terms added because a narrower term was assigned R14.
• Store controlled values with their identifiers. The IPTC "CV-Term About Image" property holds topics expressed as terms from a controlled vocabulary R15.
• Examples in the wiki: auto-tagging against the customer's taxonomy with a tag blacklist in Orange Logic ; a banned-keywords list in IntelligenceBank ; custom training of smart tags on a business taxonomy in Adobe Experience Manager Assets .
• Vocabulary design and governance are covered in Taxonomy, controlled vocabularies & thesauri.

4. Measure precision and recall on your own assets before switching on

Why. NIST's framework says accuracy measurements should be paired with realistic test sets representative of the conditions of expected use, should consider false positive and false negative rates, and may be broken down by data segment R1. "Accuracy" on its own misleads for tagging: most labels are absent from most assets, so a system that applies nothing can look accurate. Information-retrieval research uses precision and recall for this reason R18.

How.

1. Build a test set of a few hundred of your own assets, stratified by asset type (packshots, lifestyle, events, documents, video) and by source (studio, agency, user-generated). Include hard cases: logos, low light, crowded scenes.
2. Have two people tag it independently with your vocabulary, then reconcile disagreements. Where people disagree often, the label is ambiguous; fix the definition before blaming the model.
3. Run the AI on the same assets and compare, label by label:

4. Break results down by asset type and, for any feature that touches people, by demographic segment R1 R20.
5. Record the result with the model version and date. This becomes the baseline you re-test against (practice 10).

For subject-like and generated text fields, add a qualitative review: is the caption true, specific and appropriate? The LC Labs planning framework asks teams to document performance and build quality baselines during an "Experiment" phase before implementation R22.

5. Set thresholds per label, from your test results

Why. Many platforms let you set a minimum confidence, but one global number rarely suits every label. Confidence scores are often not calibrated: a score of 90 does not mean the tag is right 90% of the time R19.

How.

• For each frequent label, plot precision and recall at several thresholds on your test set, and choose the threshold that meets the target for that label's risk tier.
• Use two thresholds where the platform allows: above the upper one, apply automatically (low-risk labels only); between the two, send to review; below the lower one, discard.
• Cap the number of tags per asset to stop low-value tags flooding results.
• Vendor content sometimes proposes a single default threshold. Treat such numbers as a starting point to test, not as a standard R24.
• Examples in the wiki: a configurable minimum confidence (0–99%) and maximum number of tags in Canto ; a confidence threshold (1–99%) with a monthly tagging quota in IntelligenceBank ; confidence scores and tag moderation in Adobe Experience Manager Assets .

6. Design human review in proportion to risk

Why. The Library of Congress describes its approach as balancing human judgement with machine capabilities, with humans in the loop across its AI use cases R23. Review is costly, so spend it where errors hurt. Automation bias means reviewers may accept suggestions too easily R2.

How.

• Queue by tier, not by asset: low-risk tags flow through; medium-risk suggestions wait in a review queue (or a workflow step) before the asset is released; high-risk fields are never filled automatically.
• Give reviewers context: the suggested value, its confidence, the source model, and the vocabulary definition. Make "reject" as easy as "accept".
• Audit what was accepted automatically. Each month, sample auto-applied tags and re-measure precision. If precision falls, raise the threshold or move the label to review.
• Watch for rubber-stamping: very high acceptance rates combined with errors found later in audits suggest reviewers are not really checking.
• Let users flag wrong tags from search results, and route flags to the metadata owner.

7. Treat faces, people and sensitive attributes as a separate decision

Why. Faces bring data-protection, bias and, in the EU, AI-specific rules.

• Detection is not recognition. France's data-protection authority (CNIL) distinguishes face detection (finding a face) from recognition (identifying or authenticating a person), treats the facial data extracted for recognition as biometric data, and says any facial recognition project must undergo a data protection impact assessment (DPIA) R11.
• When a photo becomes biometric data. The UK Information Commissioner's Office (ICO) explains that biometric data results from "specific technical processing" and becomes special category data when processed for the purpose of uniquely identifying someone; it notes that inferring attributes such as ethnic origin from biometric data can also create special category data R9. Where consent is the basis, the ICO says people must be able to refuse without detriment and be offered a suitable alternative, and that organisations should know the expected false acceptance and rejection rates and check whether some groups get less accurate results R10. The ICO notes that this guidance is under review following the UK Data (Use and Access) Act R25.
• EU AI Act. Regulation (EU) 2024/1689 defines biometric categorisation and emotion recognition systems R4. Its Article 5 prohibits, among other things, building or expanding facial recognition databases through untargeted scraping of facial images from the internet or CCTV, inferring emotions in the workplace and in education (except for medical or safety reasons), and biometric categorisation to infer race, political opinions, trade union membership, religious or philosophical beliefs, sex life or sexual orientation R5. These prohibitions have applied since 2025-02-02 R8. Annex III lists remote biometric identification, biometric categorisation by sensitive attributes and emotion recognition as high-risk uses R7; after the Digital Omnibus on AI, the Commission's timeline gives 2027-12-02 for Annex III obligations R8. Article 50(3), applicable from 2026-08-02, requires deployers of emotion recognition or biometric categorisation systems to inform the people exposed to them R6 R8. The Commission notes that some article pages are not yet updated for the Omnibus amendments, so check the current text R5.
• Bias. NIST's 2019 study found that false positive rates for some demographic groups were 10 to 100 times higher than for others in one-to-one matching, varying by algorithm R12. An academic audit of commercial gender classifiers in 2018 found error rates up to 34.7% for darker-skinned women against a maximum of 0.8% for lighter-skinned men R13. These studies tested specific systems at specific dates; they show why you must test your own, not what your vendor's error rate is.

How.

• Decide explicitly whether you need recognition at all. Detection (counting faces, cropping, flagging assets that show people for release checks) carries less risk than naming people.
• If you use recognition: run a DPIA, document the legal basis, limit who may name faces and who may search by person, define how long face templates are kept, and how a person's templates are deleted.
• Switch off automatic attributes such as age, gender or emotion unless a documented decision justifies them. Review them against Article 5 and Annex III with your legal team.
• Link people to model releases rather than relying on recognition alone (see Digital rights & usage management).
• Examples in the wiki: non-biometric face detection and grouping that users name in Acquia DAM ; facial recognition used for talent-release management in IntelligenceBank ; face recognition with optional celebrity recognition in Canto .

8. Review generated captions, descriptions and alt text before publication

Why. Language models write fluent text that can be wrong, which NIST calls confabulation R2. A caption that names the wrong product, or alt text that describes something not in the image, harms accessibility and brand trust once published.

How.

• Treat generated text as a medium- or high-risk field: draft by AI, approved by a person before the asset reaches a portal, website or channel.
• Write the prompt and the expected style into your usage guidelines, and keep prompts under change control like any other configuration.
• Keep the AI flag on the field until a person edits or approves it. Sitecore Content Hub's "Generated by AI" marker is one example .
• Never let generated text overwrite rights, credit or caption fields that came from the creator or the licensor.

9. Govern providers, data flows and licences

Why. Many DAM AI features call third-party models. NIST's Generative AI profile stresses that AI value chains involve many third-party components and that errors in them can affect accuracy downstream R2. Licences also matter: the IPTC Data Mining property records whether data mining, including AI/ML training, is allowed or prohibited for an asset R15.

How.

• For each AI feature, record the provider, processing location, retention, whether your assets may be used for training, and how you are told about model changes. Several solution pages in the wiki record these points, often as Not public. Ask vendors to fill the gaps in writing.
• Ask for model documentation. "Model cards" were proposed to report a model's intended use and its performance across groups R20. The LC Labs framework asks for a data processing plan, combining model cards, data sheets and provenance details, in vendor contracts R22.
• Respect licence restrictions: do not send assets whose licence prohibits data mining or AI processing to external AI services (see practice 12 of the rights guide).
• Prefer platforms that let you switch AI features on per library, folder or asset type, and that let you bring your own model where you need one. The wiki documents a "bring your own AI" connector in Sitecore Content Hub and connections to external ML services in Orange Logic .
• If your organisation runs an AI management system, AI tagging belongs in it. ISO/IEC 42001:2023 specifies requirements for establishing, implementing, maintaining and improving an AI management system; only a summary is freely available, and the standard itself is sold by ISO R3.

10. Monitor in production and keep changes reversible

Why. NIST's framework asks for production monitoring and post-deployment plans covering user feedback, appeal and override, incident response and change management R1. Models are updated by providers, sometimes silently, and your content changes too.

How.

• Re-run the test set after every model or provider change, and at least on a fixed review cycle.
• Track a few indicators: share of suggestions accepted and rejected per label, audit precision of auto-applied tags, user flags, and zero-result searches. The guide DAM KPIs, ROI & user adoption covers measurement more broadly.
• Make every AI run reversible: you should be able to select all values written by model X version Y between two dates and remove or re-run them in bulk. This depends on practice 2.
• Keep a short incident log: what went wrong, how many assets were affected, what was changed.

11. Write it down and give it an owner

Why. The Library of Congress lists accountability, equity and protection of rights among its AI principles R23, and its planning framework provides worksheets for risk, data readiness and performance R22.

How. Publish a one-page AI metadata policy covering: features in use, fields written, tiers and thresholds, review rules, face-recognition decisions, provider list, test results and dates, and the named owner. Assign the metadata steward to approve vocabulary mappings, the legal or privacy owner to approve anything involving people, and the technical owner to run tests after model changes. Roles for the wider schema are described in the metadata schema guide.

Common pitfalls

• Switching AI on for the whole library at once. Pilot on one collection, measure, then extend.
• Trusting a vendor's general accuracy figure. It was measured on someone else's images and labels. Test on yours.
• One global confidence threshold. Some labels are reliable at a low threshold; others are poor even at a high one.
• AI tags in the same field as curated keywords, with no flag. Cleanup becomes impossible after a bad run.
• An uncontrolled second tag cloud. Unmapped model labels split facets and duplicate your vocabulary.
• Face recognition enabled "because it was in the package". Without a DPIA, a legal basis and access rules, it is a liability.
• Generated alt text and captions published without review. Fluent is not the same as correct.
• Review queues nobody owns. Suggestions pile up, or reviewers accept everything to clear the backlog.
• No re-test after a model change. Quality can shift without any change on your side.
• Losing the AI flag on export or migration. The next system treats guesses as facts.

How DAM platforms support this

Each solution page in the wiki has an AI capabilities section (and a Metadata & taxonomy section) that documents, with citations, what the platform automates and which governance controls it offers. The examples below illustrate the practices above. They are not a ranking and not an exhaustive list.

Where a page says Not public or Unknown (training use of customer data, opt-out granularity, model versions), ask the vendor in writing and test the behaviour yourself before relying on it.