AI case studies: 20 questions to separate evidence from promises.

It is the documentation of a real application with context, problem, intervention, participants, technology, governance, results and learning. It must clearly distinguish a test, a pilot, an implementation and a continuity proposal.

Solve the difficulty of evaluating whether a solution can be relevant in another context. It also brings transparency about what worked, what required human effort, and what is not yet proven.

A demo shows that something is possible; a case explains what happened in a particular organization. A representative architecture can inspire, but should not be presented as an implementation of the client.

It makes sense to document a case when there is permission, verifiable scope, accountability, and useful learning. There is no need to expect a perfect result: the limits and corrections also have value.

It should not be published if the client has not authorized, the data cannot be verified or proposals are mixed with facts. In this case a representative example identified as such can be created.

It is necessary to order initial problem, baseline, objectives, participants, chronology, sources, solution, controls, metrics and evidence. Also which parts are left out of the public narrative.

Project documents, tests, records, agreed metrics, interviews and approved materials are used. The figures need a period, definition, source and publication permission.

The client’s team, project managers, specialists, users and communication or legal. The person who owns the case validates facts and borders between confidential and public.

The AI can help sort materials, find contradictions, prepare a chronology and adapt formats. It must not invent results, testimonials, logos, quotes or commercial relationships.

People validate facts, interpretation, permissions, and language. They also decide whether a result can be attributed to the system or only described as an observation.

The tools serve to collect evidence, analyze data and publish the case. The priority is traceability, not building an impressive visualization on incomplete data.

The case must be connected to the project system, analytics and permission repository. This makes it easier to update or withdraw a claim if the evidence changes.

A first token can be prepared when there are ordered materials; validation may require several rounds. The schedule depends on permissions and data availability.

The investment is mainly time of research, analysis, validation, writing, design and approval. A rigorous case may need less production and more contrast.

It is measured by commercial and editorial utility, qualified queries, reuse and trust. But the case is also an internal tool of learning, not just grasping.

Mistakes are to inflate metrics, hide human intervention, use logos without permission and present a future idea as a result. It also removes all context to make the case universal.

It is contrasted with sources, responsible and an explicit list of claims. A final review marks each item as documented, representative, pending, or non-publishable.

It is updated if there are new phases, results or permissions. Every change must retain date and avoid rewriting the past as if the new result had existed from the beginning.

Yeah. A SME can document a small process if it explains the starting point and impact well. Credibility does not depend on the size of the project, but on the evidence.

Karmina separates documented cases from representative architectures. Aena, Associació Alba and Terrassa City Council have their own pages with different scopes; no visual structure replaces the validation of what is real.