AI Governance: A Practical Framework for Organizations (In Light of NIST AI RMF, ISO/IEC 42001, and Data Protection Laws)

AI tools enter organizations through two paths: planned projects and employee-driven shadow adoption. The latter is often invisible, which is precisely why governance is necessary: customer data pasted into a chat tool, an unverified summary making its way into a report, or no one taking responsibility for a model's decision. In this article, we propose a streamlined governance model derived from large enterprise frameworks, designed to be implemented by small and medium-sized organizations.

The frameworks we rely on

• NIST AI Risk Management Framework (AI RMF 1.0): Provides a risk-centric approach through the govern, map, measure, and manage functions.
• ISO/IEC 42001:2023: The AI management system standard; applies a management system logic similar to ISO 27001 to artificial intelligence.
• European Union Artificial Intelligence Act (AI Act): Categorizes use cases by risk levels; may create obligations for organizations doing business with the EU.
• Personal data legislation: KVKK in Turkey, the Protection of Personal Data Law in Northern Cyprus, and GDPR in the EU; while not specific to AI, every AI usage is subject to these rules.

These frameworks appear vast; however, their essence can be boiled down to four questions: What are we using? With what data? Who is responsible? What happens if an error occurs?

1. Inventory: What are we using?

The first step is to list all AI use cases within the organization: official projects, embedded software features, and tools used individually by employees. Each entry includes the purpose of use, the type of input data, where the output is utilized, and the responsible person. This inventory is the AI equivalent of the asset inventory in ISO 27001.

2. Data classification: Which data can go to which tool?

A simple three-tier classification is sufficient for most organizations: public, internal, and confidential (personal data, financial data, contracts). Rule example: confidential data can only be given to locally running models within the organization; internal data can go to services with contracted and clear data processing terms; there are no restrictions for public data. Communicating this rule to employees with a single-page guide is more effective than lengthy policies.

3. Use classes and human approval

Classify each usage according to its impact:

1. Supporting: Draft text, summary, code suggestion. Humans make the final decision; approval is structurally already there.
2. Decision support: Financial analysis, risk scoring, candidate pre-screening. Outputs are not processed without being reviewed by a human; citation is mandatory.
3. Automated action: The model's output directly triggers an action. For most organizations, this class should not be used without a clear risk assessment and rollback mechanism.

The goal of governance is not to slow down AI; it is to determine in advance which usages need to be fast and which need to be approached with caution.

4. Accountability and logging

Every AI usage must have a business owner; not the technical team, but the owner of the process where the output is utilized. Systems must log who obtained which output using what data. Without logs, neither error analysis nor accountability under regulations is possible.

5. Error and incident management

Models can produce incorrect, biased, or hallucinated outputs. The governance model defines not that this "will not happen," but "what will be done when it does": a reporting path for users to flag errors, a review of affected decisions, and temporarily halting usage if necessary. This is the AI extension of information security incident management.

6. Vendor assessment

If an external service is used, the contract must answer these questions: Are inputs used for model training? In which country is the data processed? What is the retention period? Who are the sub-processors? These questions follow the exact same logic as data processor agreements under GDPR and KVKK.

Starter kit for small teams

• A one-page usage guide (permitted tools, data classes, prohibitions).
• An inventory spreadsheet (tool, purpose, data, owner).
• A "cite and approve" rule for decision support use cases.
• A quarterly review meeting.

Sample usage guide (single page)

The text below is a fictional example of a guide an organization can distribute to its employees; it should be adapted according to the organization's own tools and data classes.

Permitted tools: Internal assistant (all data classes); contracted external service X (public and internal data only).

Never to be shared: Customer personal data, salary information, contracts, credentials; to no external tool.

Output utilization: AI drafts do not enter customers, official documents, or decisions without being read and corrected by a human.

Source: Every factual claim coming from AI must be verified with a source.

Reporting: If you notice an erroneous, biased, or suspicious output, report it to ...; reporting is never a reason for punishment.

Sample inventory table

UsageToolData ClassUse ClassBusiness Owner Meeting note summarizationInternal assistantInternalSupportingOperations Contract clause searchInternal RAGConfidentialDecision supportLegal Social media draftExternal service XPublicSupportingMarketing Cash flow forecastingInternal modelConfidentialDecision supportFinance

Technical controls: Connecting policy to code

Governance cannot run on documents alone; systems must enforce the policy:

• Permission-filtered access: The assistant cannot see data that the user cannot see (at the database level).
• Logging: Every query and response is stored with user and timestamp data; access rights and retention periods are defined.
• Approval gate: Outputs in the decision support class do not advance in the workflow without a human "approved" flag.
• External service gateway: Requests going to external services pass through a single gateway; confidential data is blocked and logged at this gateway.

Measurement: What to track?

The "measure" function of the NIST AI RMF can be reduced to three simple indicators for the organization: the number and type of reported errors, the rate of outputs rejected in human approval (trend rather than a numerical target), and the detection of out-of-inventory usage. These indicators are addressed in quarterly reviews; the goal is not punishment, but the improvement of rules and tools.

Frequently asked: "Won't this slow us down?"

A well-designed governance model places almost no restrictions on supporting uses; it pre-determines the uses that require caution. What slows things down is not governance, but ambiguity in rules: an employee who doesn't know which tool can be used either never uses it or uses it incorrectly. Clarity is a prerequisite for speed.

At Cy Logic, we treat validation, authorization, and audit logging as mandatory components in the AI systems we develop; the governance model is the organizational side of this and must be designed alongside the technical architecture.