Fairtrade communications staff around the world really appreciate ResourceSpace. It's proven invaluable as a one-stop for sharing and storing all our images and brand assets. I don't know how we'd manage without it!
Blog
12th June 2026

Author: Ralph Windsor
Ralph Windsor is an independent DAM consultant and regular DAM News contributor. Having worked with Digital Asset Management systems for over two decades, he advises organisations on DAM strategy, metadata, governance and emerging technologies, with a particular interest in the practical application of AI.
Anyone who has spent more than ten minutes inside an enterprise DAM system knows the unique despair of searching for a specific file. You type in 'Q3_campaign_hero' and get either zero results or forty identical thumbnails named some variation of hero_image_final_v7_ACTUAL_FINAL.jpg.
For years, the DAM software industry’s solution to this human messiness has been rigid discipline: stricter categorisation, controlled vocabularies, enforced taxonomies and endless drop-down menus. Electronic filing cabinets were built and users were required to learn how to become better clerks.
Now, Artificial Intelligence is threatening to blow up the idea of a filing system entirely. Large Language Models (LLMs) have moved from research labs into enterprise software so quickly that the industry is scrambling to figure out what a DAM should even look like anymore. This identity crisis usually boils down to two entirely different issues that keep getting mashed together: how we talk to the DAM (the interface question) and what the DAM actually knows about our files (the knowledge question). Conflating the two is a recipe for expensive, unusable software. In order to better understand these issues, we need to look at them separately.
The traditional DAM interface, an endless grid of thumbnails, file type checkboxes and drop-down menu filters, is boring, but also brutally precise. If you filter for licensed images expiring in 2026 with a landscape orientation, the system gives you exactly that. It doesn’t guess or try to be creative.
The primary weakness of the conventional Graphical User Interface (GUI) is that you have to speak its language. If the marketing team tags something as 'apparel' but an intern in the design team searches for 'clothing', the DAM system is dumb and zero results are returned. The interface is only as good as the metadata behind it – and let’s be honest, metadata quality in most organisations is rarely satisfactory.
The idea of just typing, 'Find me that wide shot of the winter coat without anybody in it from last year', is an enormously appealing proposition; natural language is the ultimate accessibility tool. An AI interpreter maps the user's messy, colloquial intent onto the system's rigid tags – no taxonomy training required.
Looking at how software developers use AI offers a perfect argument for keeping our metadata exactly where it is. Coders may be starting to use AI to generate boilerplate, test ideas and accelerate their workflow, but they aren't abandoning their IDEs or their version control just yet. The reason is straightforward: AI assists with the creative and generative parts of the job, but when it comes to the precise, auditable, deterministic work (i.e. tracking exactly what changed, when and why), you need tools that don't guess. A DAM's GUI is that kind of tool – it doesn't interpret your search, it executes it. And in an environment where a wrong retrieval result can carry legal or financial consequences, that's a risk-avoidance feature worth protecting.
The same logic applies to a DAM. In a consumer chatbot, a wrong answer is a minor annoyance; hallucinations and the occasional non-sequitur are now par for the course. In a DAM, a wrong answer can be catastrophic. If a probabilistic AI model confidently hands you an image of a celebrity whose usage rights expired three years ago and you put that on a global billboard, you don't have a quirky tech glitch on your hands – you have a multi-million dollar copyright lawsuit.
AI chat interfaces are fantastic for discovery. They are great for onboarding new users who find the traditional interface intimidating, or for surfacing assets you didn't know existed. But the chances are they'll have to sit alongside the GUI, not replace it. The grid of thumbnails might have to remain the ultimate source of truth simply because it's the only way you can be sure there's no AI middle-man tinkering with your searches.
When the role of the administration side of DAM (managing the assets) comes into play, the necessity to have clear cut graphical interfaces becomes even more apparent. If you are a digital asset manager and it is absolutely critical that the rights information for an asset is fully and accurately recorded, a prompt-oriented tool is just not precise enough to be safe to use. Certainly, the concept of composable AI where LLMs are used to accelerate tagging and metadata creation can have substantial value. It is essential, however, that Digital Asset Managers can get into real depth and see exactly what is happening. Graphical interfaces remain essential for this task and will continue to do so.
A further, related intriguing issue is what a DAM system actually understands about the files it holds and where responsibility for that should end.
Right now, a standard DAM can be regarded as a smart envelope reader. It knows a PDF exists, it knows it was uploaded on Tuesday by Sarah in Marketing and that it has been tagged 'Brand Guidelines'. Aside from some potential indexing of the text content, It has no idea what the purpose of the PDF is.
That limitation is now disappearing. Modern multimodal models (like Gemini and Claude) don't just process text; they can natively read documents, transcribe audio and 'see' the contents of a video without needing a human to tag them first. Through Retrieval-Augmented Generation (RAG), the contents of your assets can be broken down, indexed, contextualised and made entirely searchable.
You can now ask a system, 'What are our rules for using the logo on a dark background?' and the DAM could read the 80-page brand PDF and output the exact rule.
The potential value here is huge. Most companies are sitting on a vast archive of institutional knowledge: email threads, recorded webinars that nobody re-watches, exhaustive onboarding decks and legacy brand guidelines that are technically available but practically useless because nobody can be bothered to read them. It's a rich seam that AI is spaniel-happy to mine.
However, if you’ve spent any time working with RAG in production environments, you will have probably come across a fundamental flaw: LLMs are practically incapable of admitting ignorance, at least on an initial query.
When you ask an LLM a question and the answer isn't in the available documents, the model rarely admits that it is unsure. The probabilistic reasoning that underpins LLMs requires it to close an open loop by inventing a rule about logo usage that sounds highly plausible and could be entirely wrong. This isn't a bug; it’s by design.
In an enterprise environment, a 95% accuracy rate is essentially a 0% trust rate if the 5% of failures look exactly like the successes. If a user can't tell when the system is hallucinating a brand guideline or a contract term, they will stop using the system entirely.
The only way to mitigate this is to force the AI to show its work. Unlike a standalone chatbot that pulls answers out of thin air, a DAM-integrated system has the distinct advantage of actually holding the source files. If a DAM is going to synthesize answers, it has to cite its sources: 'This answer is drawn from page 4 of the Brand Guidelines, last updated March 2024'. The moment the interaction shifts from 'Here is the answer' to 'Here is the answer and here is a link to the document so you can check my sums', the system actually becomes more trustworthy. If the end user subsequently accepts inaccurate suggestions without checking them, there is a paper trail of decisions which can be audited.
So, should a DAM make the leap from a file repository into an AI knowledge engine?
Yes, but we need to be realistic and precise about what we are building. The assets are already sitting there and the tools to extract knowledge from them are readily available. It makes no sense to leave that value on the table, but the obligation to show its working shouldn't stop at the system architecture; it should extend to the vendors selling these tools and the organisations choosing to deploy them.
Vendors and organisations need to be transparent about the limits of these tools. We don’t need black-box systems that are designed to know everything about a company’s history or institutional knowledge. Instead, solutions that act as helpful pointers – suggesting the relevant paragraphs, highlighting the exact video timestamps and then promptly ducking out of the way so a human professional can make the final call.
LLMs will get better at acknowledging their own limitations. But for the foreseeable future, the true value of an AI-powered DAM will be its ability to prove exactly where its answers have come from.
A wider commercial point the industry might have to answer is whether there is any value in getting deeper into the Knowledge Management aspect of DAM. This is an idea that has kicked around the edges of the industry for the last two decades. Without AI, it was impractical for most vendors to seriously contemplate. With the availability of commodity LLMs, it becomes more feasible. Because of that fact, however, it seems inconceivable that the developers of LLMs (who are nearly all tech behemoths) will not, themselves, be developing software to carry out this function.
As with many aspects of modern Digital Asset Management, is the function of a DAM more to hand off tasks to third party solutions rather than writing yet more features? DAM software products are already bloated with a wealth of capabilities (many of which are untouched by their users). Do they need more? I would argue, probably not, especially when to do so would potentially place them in competition with the LLM providers. Providing some kind of prompt-oriented window into LLM-generated content insights and converting that into knowledge has some value, but it would be unwise for vendors to over-reach and spread themselves even thinner than they already are. Once again, the concept of Composable AI offers the answer here. The DAM should orchestrate rather than generate.
As ever with DAM, integration and getting someone else to develop features is going to be more profitable, more efficient and more useful for end users.
![]()