01Analysis and brief
Define the use case, select examples and agree criteria.
Format
Test AI's potential with your own data
The proof of concept investigates whether a selected technical approach can handle a specific task. Its scope stays focused on that question. Full production operation is a separate stage.
| Area | In the proof of concept | For operation |
|---|---|---|
| Task | Evaluate a limited use case | Implement the agreed complete process |
| Testing | Selected examples and defined criteria | Acceptance cases and operating requirements |
| Integration | Data and interfaces needed for the question | Production integration and responsibilities |
| Outcome | An informed decision on whether to continue | An approved application under the agreed operating model |
Basis for a decision
Your sample data reveals the potential
General success rates say little about your use case. What matters is how the selected approach handles the agreed examples and how much follow-up work its outputs require.
Selection
Test the value of an AI use case
Good starting points have an output that can be reviewed, such as a report draft from approved data, relevant passages found in documents, or specified fields extracted from forms. A subject-matter user must be able to judge what is correct, incomplete or unusable. Test cases and the required comparison results are assembled before implementation.
Assessment criteria
Agree on shared success criteria
Evaluation criteria follow the task: are all required details present, are statements supported by sources, how often do errors occur and how much rework remains? Response time and cost per processed case may also matter. Edge cases and unsuitable inputs are included. Before building, we define which outcomes justify expansion, a different approach or ending the experiment.
Institutional approval
Connect the pilot with your workflow
The proof of concept receives a business owner, a defined intended use and explicit usage boundaries. The institution places it within existing change and approval processes, including any relevant MaRisk process. Business and control functions understand the criteria, data scope and decision to be made at the end of the experiment.
A test needs an agreed framework.
Technical testing supplies results, failure cases and outstanding development needs. It does not pre-empt the business decision about future use.
Test data
Choose data to match the question
Synthetic examples or approved documents may be sufficient for an initial test. Some tasks can only be assessed when the AI processes content. The required data access is therefore described and agreed before starting.
Use boundaries
Describe the intended later use
For AI governance, we describe the use case, users, model, data types, outputs and human review. This supports assessment of the specific deployment, for example in an AI inventory and under the EU AI Act. Testing reveals which errors a person must detect and where a refusal or handover is needed.
Technical framework
Consider integration and operation early
A technical profile records required services, interfaces, access permissions and dependencies. Logging, failure handling, support and information needed for third-party management are considered for subsequent institutional use. The proof of concept integrates only what its test question requires.
The technical experiment provides a basis for the next decision.
Later introduction has its own scope and responsible participants.
| Item | Agreement | Timing |
|---|---|---|
| Evaluation question | Task and expected result | Before building |
| Test data | Examples and permitted access | Before processing |
| Assessment | Criteria and responsible people | Before assessment |
| Further operation | Connections and required prerequisites | Before the implementation decision |
Approach
Use the established T-NEX process
Analysis and design lead to a limited prototype, tested against the agreed examples. The conclusion records results, limits and necessary rework. An expansion is scoped separately to cover additional data connections, permissions, business approvals, monitoring and support. This lets the proof of concept lead to a grounded next decision.
02Design and prototype
Review the proposed workflow with your business team early.
03Development and testing
Build the agreed experiment and assess results together.
04Decision and handover
Discuss findings and record the next step or the end of the experiment.
About the format
Frequently asked questions
Describe the task you want to test
A specific workflow and an example of a good result are enough to begin. We will discuss how to turn them into a limited experiment.
Discuss a use caseCriteria and scope are defined before building.
Sources & further reading
In-depth articles
- AI agents in banking: operating limits and control
AI agents in financial institutions: limit tasks and permissions, assess approvals and trace actions under MaRisk, DORA and the AI Act.
- MaRisk 2026: current version and requirements
MaRisk under Circular 06/2026: scope, structure and relationship with DORA, including the limited transition and investment-firm distinction.
- DORA for financial entities: duties and implementation
DORA since 17 January 2025: scope, ICT risk, incident reporting and third parties, with primary sources and implementation checks.