How We Approach an AI Project at Ideasweb: From a Concrete Problem to a Controllable Solution

An artificial intelligence solution should not begin with “which tool should we use?” A more useful question is: which task, decision, or user journey needs to improve, and how will we verify it?

At Ideasweb, we treat AI projects as part of a real operation. That means understanding the context, agreeing on what the solution can and cannot do, reviewing the sources that support it, and preserving ways for people to supervise it. Technology matters, but it does not replace problem definition or the responsibility of the people using it.

AI creates value when it removes a specific friction without making the process it is meant to improve opaque.

This approach is consistent with widely used criteria for trustworthy AI risk management: governance, context, evaluation, and risk management. The NIST AI Risk Management Framework groups these activities into govern, map, measure, and manage. The OECD AI Principles also emphasize transparency, human oversight, robustness, and accountability according to the context of use.

1. We start with the problem, not the model

Before proposing automation, we ask operational questions. Is the team spending too much time finding information? Are support answers repeated constantly? Is scattered data making a task harder? Does a process need to classify, summarize, or route cases?

The goal is not to add AI because it is fashionable. It is to define an observable improvement and determine whether AI is a reasonable option compared with process changes, better forms, conventional rules, or training.

What we define at this stage

• The user or team experiencing the friction.
• The current task and the specific point where it is slow, repetitive, or error-prone.
• The intended outcome: guide, classify, summarize, extract, assist, or automate a limited action.
• The cases that must remain out of scope.
• How to measure whether the solution is genuinely helpful.

This prevents broad promises such as “automate everything” and makes it possible to build a first version that can be reviewed.

2. We define scope, sources, and permissions

A convincing answer is not always a correct one. For that reason, when a solution uses internal information, we prioritize identifying valid sources, the people who maintain them, and how often they change.

We also define what data the solution may consult and what actions it may perform. If an AI system interacts with internal systems, it should not have more permissions than necessary for its task. Access, traceability, and the ability to intervene are designed from the outset rather than after an incident.

Questions to answer before connecting data

1. Which documents, databases, or systems will provide information?
2. Who confirms that the content is current and appropriate for this use?
3. Which personal, confidential, or sensitive data must be excluded or protected?
4. Will the solution only inform, suggest an action, or execute it?
5. When must it route the case to a person?
6. What record will remain of requests, responses, and actions?

The NIST AI RMF 1.0 states that risk management should be considered throughout design, development, deployment, and use. In practice, that means sources, permissions, and accountable owners are not secondary technical details.

3. We design an experience with visible boundaries

A useful solution should communicate what it can do, where its limits are, and what someone should do when the result is insufficient. This is especially important for assistants, internal search tools, and automations that generate text or recommendations.

Depending on the case, we include scope notices, references to the information used, correction options, routing to an accountable team, and confirmation controls before important actions are performed. The goal is not to transfer every decision to a system, but to provide assistance that is clear and proportionate to the risk.

4. We test with real cases before expanding use

Before making a solution available broadly, we prepare representative cases: frequent questions, ambiguous situations, out-of-scope requests, incomplete information, and scenarios that need human routing.

Testing is not about proving that AI “never fails.” It is about learning how it fails, when it needs more context, and when it should stop. We assess:

• Practical usefulness and accuracy of responses or outputs.
• Respect for defined sources and rules.
• Its ability to acknowledge uncertainty or missing information.
• Behavior under unexpected instructions or misuse attempts.
• The quality of routing to a person or alternative flow.
• Whether there is enough logging to review incidents and improvement opportunities.

NIST explains that govern, map, measure, and manage are not isolated phases or a rigid checklist; they are functions that inform one another over a system’s lifecycle. That principle is central to our work: an initial implementation should create learning rather than end the conversation.

5. We support operational rollout and improvement

Publishing a solution does not mean the project is finished. Once it is in use, we review requests, recurring mistakes, routed cases, source changes, and signs that the scope needs adjustment.

Improvement may involve updating content, refining instructions, restricting an action, adding a validation, or changing a user flow. Not every problem is solved by adding more automation.

What an organization can expect from this approach

The expected result is not a promise of perfect answers. It is a focused, documented solution prepared to operate with greater clarity. When the case calls for it, the process can include:

• Needs assessment and objective definition.
• User-flow design and oversight points.
• Review of sources, data, integrations, and permissions.
• A first build with limited scope.
• Testing with real cases and acceptance criteria.
• Implementation, monitoring, and prioritized improvements.

A practical way to begin

If you are considering AI for your organization, choose one specific process and describe it on one page: who performs it, what information it uses, where it gets stuck, what error would be unacceptable, and how you would know it improved. With that foundation, you can decide whether an AI solution is appropriate, which controls it needs, and what its first version should be.

Would you like to assess a specific need? At Ideasweb, we develop artificial intelligence solutions for real processes, experiences, and systems, with the scope and controls each case requires.