AI integration in organisations: where to start and what to watch for

The safest way to begin AI integration in an organisation is with a single process that is repetitive, text-heavy and cheap to get wrong. The data that process will use should be assessed under KVKK from the outset, every output the AI proposes should be approved by a person, and the result should be measured against criteria set at the start. A small, bounded pilot lets the organisation see both the technology and its own readiness under real conditions.

Which process should AI integration start with?

Many AI projects fall short not because the technology is inadequate but because the wrong process was chosen. Starting with «Which of our tasks are repetitive, time-consuming and governed by clear rules?» instead of «Where can we use AI?» gives a starting point grounded in a real need. The first project should target the routine work that takes up most of staff time, not the organisation's most critical decisions.

For associations, educational institutions, journal and congress secretariats and small businesses, good starting examples look alike: sorting incoming emails by topic, drafting replies to frequent questions, summarising long documents, pre-checking application files against formatting rules, extracting task lists from meeting notes, or searching an internal archive. What these tasks share is that a person can check the output quickly.

When choosing a process, weigh the following criteria together.

• The task recurs often and takes up a noticeable share of staff time today.
• What a correct result looks like can be defined, and a person can check it quickly.
• A wrong output cannot harm people or the organisation's reputation without being noticed.
• The process ideally involves no special categories of personal data, or that data can be stripped out.
• The process's current performance can be measured well enough to allow a comparison.

What should you watch for on data privacy and KVKK?

Every piece of text sent to an AI tool is a data transfer. Sending content that contains personal data, such as member records, student details, application files, documents with health information or donor lists, to an external service is an operation that must be assessed under KVKK. Where the service processes and stores the data, whether it uses it to train models and how long it keeps it are questions to answer before any tool is chosen.

In practice, the most effective safeguard is not to send data unless it is needed. Removing or pseudonymising personal details, sharing only the fields the task requires and putting in writing which data must never be entered into which tool reduce most of the risk. Using services that process data abroad, privacy notices and contracts with data processors require separate legal assessment.

This article is not legal advice; regulations and authority decisions can change over time. Current obligations should be checked against the official sources of the Personal Data Protection Authority and with the organisation's own legal adviser. What the technical team must deliver is that those decisions are actually enforced in the system: access permissions, record-keeping and data going only where it is allowed to go.

Once an AI tool does more than produce text and is connected to the organisation's systems, for example searching a document archive or reading records, permissions become important too. The tool should never reach data the person using it could not see, and operations that can change records should not run without human approval. It also has to be assumed that instructions hidden inside an incoming document or email may try to steer the tool, so tools should be given the lowest level of access they need.

Why is human approval indispensable?

Large language models can produce extremely fluent and persuasive text, but that text is at times wrong, incomplete or detached from context. A model can write something it is unsure about in the same confident tone. In institutional use, the role of AI should therefore be to prepare suggestions and drafts, not to make decisions.

Decisions that directly affect people in particular, such as accepting a membership application, assessing a scholarship, an editorial decision on a paper or article, or aid given to a beneficiary, should never be left to AI output alone. In these processes AI can flag a missing document, prepare a checklist or summarise a long file; the authorised person makes the decision.

For human approval to work, it has to be visible in the system. Which text was proposed by AI, who approved or changed it and when it was sent should all be recorded. That record makes it possible to understand the cause when something goes wrong and protects the organisation's accountability.

The right division of roles for AI in organisations is simple: the AI suggests, a person decides, and the system keeps the record.

How do you measure the success of an AI project?

Measurement starts before the project does. Unless you record how long the chosen process takes today, how often mistakes are made and how much rework it needs, there is no way to say at the end of the pilot whether anything improved. A sense that «it seems faster» is not a sufficient basis for budget and scope decisions.

Useful measures typically include time spent per task, the share of outputs corrected during human review, the number of errors that slipped through, staff and service-user satisfaction and the total cost of the tool. Alongside the numbers, it is important to collect staff observations about the tool regularly, because the person who uses it every day is the one who sees best when it gets things wrong.

The correction rate is particularly revealing. If most outputs are rewritten from scratch during review, the tool is not saving time but merely moving the work to another step. In that case, improving the instructions, narrowing the process or dropping that task may be wiser than increasing the investment.

Cost measurement should include not only the tool's subscription or usage fee but also the human time spent on approval, the effort of training and setup and the cost of correcting possible errors. At the end of the pilot, the question answered is then not «how much did the tool cost» but «how much better did the process work overall».

How do you set up a small pilot project?

A pilot is a bounded trial of AI under real working conditions before it spreads across the organisation. Its scope should be narrow, its duration fixed and its success criteria written down in advance. The point of a pilot is not only to see whether the technology works but also to understand how ready the organisation's processes, data and team are for the change.

A well-designed pilot follows these steps.

• A single process and a small team responsible for it are chosen.
• The process's current duration, error rate and cost are recorded.
• Which data will be used, and which will never be used, is set out in writing.
• A flow is set up in which the AI only produces suggestions and approval stays with a person.
• At the end of the set period, results are compared with the baseline measurements.
• The decision to expand, adjust or stop is made on the basis of that comparison.

It matters that stopping is accepted as a legitimate outcome from the start. A pilot that does not deliver is not a failure; it protects the organisation from a bigger mistaken investment. What is learned at the end of a pilot also guides the choice of the next process.

How do you set internal usage rules?

Even before the organisation makes a formal decision, some staff may already be using AI assistants with personal accounts. That informal use can mean organisational data going to external services without oversight. Banning it often just makes the problem invisible; clear, workable rules are more effective.

A short usage policy should define which tools may be used for organisational work, which kinds of data must never be entered into them under any circumstances, when content prepared with AI should be disclosed and who is responsible for approval. Sharing the policy alongside brief training and explaining it with concrete examples makes it more likely the rules are actually followed.

• Only tools approved by the organisation, and organisational accounts, are used for its work.
• Identity details, health data, financial information and passwords are never entered into any AI tool.
• External correspondence prepared with AI is read by the responsible person before it is sent.
• Information produced by the tools is not carried into official documents or publications without its source being verified.
• It is clear when the rules will be reviewed and who answers questions about them.

Skills have to grow alongside the rules. An environment where staff can learn by trying what AI does well and badly, and where wrong outputs can be discussed openly, improves both productivity and safety. Having the staff who use the tools best share their experience with the team is the quickest way for an organisation to build its own examples of good practice.

Frequently asked questions

Does AI integration require a large data infrastructure?

Not for the first steps. Tasks such as summarising documents, drafting replies or classification can start with existing documents and emails. Even so, data that is orderly, current and governed by defined access rights directly affects the quality of the result at any scale.

Can large language models run on the organisation's own servers?

Yes, some open-weight models can be run on the organisation's own infrastructure. That keeps data inside the organisation but also places responsibility for hardware, maintenance and updates on it. The choice should balance the sensitivity of the data against the cost of running it.

Who is responsible for an error in AI output?

For the organisation, responsibility lies with whoever approves and uses the output. That is why the approval step must be recorded in the system and decisions affecting people must never be left to AI alone. Contractual and legal liability questions should be assessed separately with a legal adviser.

How long should a pilot run?

There is no fixed length; it should be long enough to complete the process's natural cycle at least once, yet short enough not to delay the decision. For a task that recurs monthly, for example, observing a few cycles gives far more reliable results than a one-off trial.

What should the first step be?

The first step is not choosing a tool but choosing one process, measuring how it performs today and writing down which data may not be used. Once those three decisions are clear, choosing a tool and designing the pilot become much faster and more accurate. At Bir Web Ajans, in custom system projects we design AI-assisted steps the same way, starting from process analysis and leaving the final decision to a person.