Menu Close
Close
Get in Touch

The kōdōkalabs
AI Ethics & Safety Statement

HomeAI Ethics & Safety Statement

AI Ethics & Safety Statement

This document explains kōdōkalabs’ current approach to using AI responsibly in its own work. It does not replace client-specific legal, security, privacy, or regulatory review, and it should not be relied on as a substitute for a client’s own AI governance obligations.

Status: Approved
Effective date: 29.03.2026
Policy owner: Founder and CEO until responsibility is formally delegated
Review cycle: At least annually and after a material change in law, system, vendor, use case, workflow, or incident

1. Purpose and Scope

kōdōkalabs helps organizations design, implement, govern, and transfer ownership of AI-powered marketing systems. AI may support research, analysis, drafting, workflow design, agent implementation, measurement, training, and operational improvement. Human expertise remains responsible for the business purpose, evidence, decisions, approvals, and consequences of that work.

This statement applies to:

  • kōdōkalabs’ internal use of AI systems;
  • research, content, analysis, architecture, and advisory deliverables;
  • workflows and agents designed or implemented for clients;
  • people operating AI systems on behalf of kōdōkalabs;
  • contractors, implementation partners, and future employees when acting within a kōdōkalabs engagement;
  • public content and other outputs published under the kōdōkalabs name.

Client-specific contracts, instructions, data classifications, risk requirements, and approval rights take precedence where they impose stricter controls. A client remains responsible for the decisions and obligations associated with its organization, systems, data, industry, and jurisdiction.

2. Our Responsible AI Principles

Responsible AI is treated as an operating discipline rather than a set of abstract values. Each principle must connect to a decision, control, record, or accountable person.

  • Human accountability: A named person owns the purpose, evidence, review, approval, and escalation decision. AI systems do not act as final accountable decision-makers.
  • Proportional oversight: Review intensity increases with factual sensitivity, reversibility, personal data, legal or financial consequence, public exposure, brand risk, and customer impact.
  • Data protection: Information is classified before AI use. Only the minimum data required for an approved purpose may be used.
  • Evidence and traceability: Material claims and recommendations must be traceable to an approved source, observation, calculation, or clearly identified assumption.
  • Transparency: AI interactions and AI-generated or materially manipulated content are disclosed when required by law, contract, platform rules, client policy, or the kōdōkalabs transparency policy.
  • Fairness and harm awareness: Relevant outputs are reviewed for exclusion, stereotyping, discriminatory impact, manipulation, and foreseeable harm.
  • Intellectual-property awareness: Rights, permissions, licences, confidential inputs, attribution, and intended reuse are considered before material is used or published.
  • Security and misuse prevention: AI systems may be used only for approved purposes, with approved access and without bypassing technical, contractual, or organizational safeguards.
  • Continuous improvement: Errors, incidents, model changes, user feedback, and regulatory developments feed back into the policy and workflow design.

3. The Responsible AI Control Stack

kōdōkalabs uses a seven-layer control model to connect responsible-AI principles to delivery work. This is a kōdōkalabs operating model, not an external standard or universal compliance framework.

  1. Business purpose and authorized use – define the outcome, user, owner, boundaries, and acceptable use before selecting a model or automating a task.
  2. Data and knowledge controls – classify inputs, identify canonical sources, minimize data, confirm access rights, and record relevant limitations.
  3. Model and vendor selection – assess whether the system is suitable for the purpose, data, risk, required oversight, and operating environment.
  4. Workflow and access controls – define permissions, handoffs, review stages, external actions, deployment boundaries, and exception handling.
  5. Human review and decision rights – assign qualified reviewers and final approvers in proportion to the use case and its consequences.
  6. Monitoring, documentation, and escalation – retain appropriate decisions, evidence, changes, errors, and incident records.
  7. Learning and policy updates – use performance evidence, incidents, user feedback, vendor changes, and legal developments to revise the system.

No single layer is treated as sufficient on its own. A human approval step cannot compensate for unsuitable data, an inappropriate system, or an undefined business purpose.

4. Human Accountability and Decision Gates

kōdōkalabs is founder-led. Until responsibilities are formally delegated, the Founder and CEO is the policy owner and final escalation point for kōdōkalabs assessments, architecture engagements, advisory work, and material exceptions to this policy.

AI-assisted work is designed around three human decision gates:

  • Source and evidence approval – Are the inputs permitted, relevant, current enough, and traceable? Are evidence gaps visible?
  • Strategic and editorial approval – Does the output fit the business purpose, audience, context, brand, source evidence, and applicable risk requirements?
  • Publication, deployment, or scale approval – Is the work ready to reach users, affect a live system, take an external action, or be expanded?

An AI system may recommend, organize, transform, or generate material within an approved workflow. It may not approve its own evidence, waive a control, accept legal or commercial risk, or authorize its own production deployment.

5. Authorized, Restricted, and Prohibited Uses

The following matrix is the proposed baseline acceptable-use policy. A client contract, law, platform rule, or approved project control may be more restrictive.
Classification
Examples
Required treatment

Authorized

Research using public or approved sources; summarization; ideation; draft outlines; first-draft content; translation; routine data transformation; code assistance in a non-production environment; workflow prototyping; training exercises using approved material
Use an approved system for a defined business purpose. Verify material claims and obtain the human approvals required by the workflow.

Restricted

Confidential client information; personal data; production code; external publishing; agent actions in client systems; automated customer communications; material financial or performance analysis; public-interest content; realistic synthetic media; high-impact recommendations; system integrations; decisions affecting an identifiable person
Complete use-case, data, vendor, access, legal, privacy, security, and human-review checks appropriate to the risk. Obtain explicit approval before use or deployment.

Prohibited

Uploading credentials or secrets into an unapproved system; deceptive impersonation; undisclosed in-scope deepfakes; fabricated sources, testimonials, credentials, case studies, or performance evidence; discriminatory profiling; unlawful surveillance; bypassing safeguards; autonomous legal, employment, credit, insurance, healthcare, or similarly consequential decisions; malware or unauthorized access; publishing unreviewed AI output as verified fact
Do not proceed. Escalate any attempted or accidental use to the policy owner.
The absence of a use case from the table does not make it authorized. New or ambiguous uses require classification before implementation.

6. Data, Privacy, and Confidential Information

Data must be classified before it is entered into, retrieved by, or made available to an AI system.
Data class
Examples
Baseline AI-use rule

Public

Published webpages, public reports, approved press material, public product information
May be used for an authorized purpose, subject to rights, source, accuracy, and platform rules.

Internal

Non-public processes, draft content, internal instructions, unpublished strategy without client secrets
Use only in an approved environment with a defined owner and access boundary.

Confidential

Client strategy, commercial data, unpublished research, proprietary workflows, contractual information
Use only when the client or information owner has authorized the purpose and the selected environment has passed the required review.

Restricted

Credentials, authentication data, special-category personal data, highly sensitive personal or financial information, regulated secrets, data whose disclosure could create material harm
Do not enter into an AI system unless the specific use has received documented legal, privacy, security, contractual, and technical approval.

Data minimization applies across all four classes. A workflow should use the least sensitive and smallest amount of information capable of supporting the approved purpose. Pseudonymized, aggregated, synthetic, or redacted information should be preferred when it can meet the same need.

Client information must not be repurposed for unrelated training, demonstration, marketing, benchmarking, or product development without an approved basis. Data retention, deletion, international transfer, access, and subprocessor requirements must be defined for the selected system and engagement rather than assumed from the tool category.

For information about personal data processed through the website, see the Privacy Policy. Project-specific data handling is governed by the applicable agreement and approved project documentation.

7. Models, Vendors, and Third Parties

Model selection begins with the intended purpose and risk of the workflow. Novelty, popularity, output fluency, or benchmark performance is not enough to establish suitability.

Before a model, vendor, integration, or agent platform is approved for a material use case, the review should consider:

  • intended purpose and foreseeable misuse;
  • data submitted to and generated by the system;
  • data retention, training use, deletion, and subprocessor terms;
  • hosting, access, account, authentication, and administrative controls;
  • contractual allocation of responsibilities and relevant client requirements;
  • model limitations, documentation, output traceability, and available provenance;
  • ability to apply human review, logging, approval, and deployment controls;
  • integration permissions and potential external actions;
  • intellectual-property and content-use considerations;
  • material model or terms changes;
  • portability, exit, and replacement options;
  • suitability for the affected people, market, language, and context.

Approval applies to a defined use case, data class, workflow, and configuration. It is not blanket approval for every use of the same product. A material change in vendor terms, model behavior, integration scope, data handling, ownership, or intended purpose triggers review.

kōdōkalabs does not claim that a third-party system is error-free, unbiased, secure in every context, or suitable for an unreviewed client use case.

8. Knowledge, Sources, and Factual Integrity

AI-generated text is not treated as evidence merely because it is fluent or confident. Material factual claims must be checked against an identifiable source, approved data, direct observation, or reproducible calculation.

The source process follows five rules:

  1. Use canonical client sources and primary or authoritative external sources where available.
  2. Distinguish sourced facts, client assertions, calculations, professional judgments, and assumptions.
  3. Verify quotations, names, dates, statistics, legal references, product claims, and performance claims before publication or delivery.
  4. Do not create a citation, quotation, result, case study, testimonial, or credential that cannot be traced to evidence.
  5. Where evidence is unavailable, state the gap and reduce the confidence or scope of the conclusion.

Research performed with AI assistance receives the same scrutiny as generated prose. Search summaries and model outputs can help locate or organize evidence; they do not replace examination of the underlying source.

When a material factual error is confirmed, the affected output is corrected or withdrawn as appropriate, the owner is informed, and the workflow is reviewed to determine whether a source, prompt, review, integration, or approval control should change.

9. Risk-Based Human Review

Human review is assigned according to the consequences of being wrong, not only the amount of AI-generated material.
Review level
Typical characteristics
Minimum treatment

Level 1 — Routine

Reversible, internal, non-sensitive, low public exposure, no personal data or material decision impact
Competent operator reviews the output before use.

Level 2 — Material

Client-facing or public content, material brand impact, performance analysis, significant factual claims, or moderate operational consequence
Subject-matter review plus evidence and strategic/editorial approval.

Level 3 — Sensitive

Confidential data, personal data, regulated subject matter, realistic synthetic media, external system actions, material financial or customer impact
Named business owner plus relevant legal, privacy, security, technical, or editorial review before release or deployment.

Level 4 — Prohibited or exceptional

Prohibited use, uncontrolled high consequence, insufficient evidence, unacceptable rights impact, or a risk that cannot be reduced within the engagement
Do not proceed. Escalate to the policy owner and client decision-maker where applicable.

Relevant risk factors include factual sensitivity, reversibility, data sensitivity, legal or financial consequence, public exposure, brand impact, affected persons, vulnerability of the audience, autonomy, system access, and the feasibility of monitoring and correction.

This matrix supports internal decision-making. It does not determine a system’s legal classification or replace client-specific regulatory analysis.

10. Bias, Fairness, and Harmful Output

Fairness is contextual. A generic check cannot establish that an output or system is fair for every audience, market, language, or decision.

Where relevant to the use case, review considers:

  • whether people or groups are represented inaccurately, stereotyped, excluded, or treated differently without a legitimate reason;
  • whether source material or training examples contain historical or sampling bias;
  • whether language, culture, disability, age, gender, ethnicity, nationality, religion, or other characteristics affect output quality or access;
  • whether the workflow could manipulate, deceive, harass, exploit, or create foreseeable harm;
  • whether a person can understand the system’s role, challenge an outcome, or reach a human;
  • whether testing includes the markets, languages, edge cases, and affected users relevant to deployment.

    Potential harmful or discriminatory output is not silently rewritten and released. It is documented and escalated when it indicates a broader problem with the source material, model, prompt, workflow, access, or intended use.

11. Intellectual Property and Content Rights

AI use does not remove the need to assess rights and permissions. Before external material is used or an output is published, the workflow should identify:

  • who supplied the source material;
  • whether it is public, licensed, client-owned, confidential, or subject to use restrictions;
  • whether attribution, permission, reservation of rights, or platform terms apply;
  • whether a generated output may reproduce protected or confidential material;
  • whether a person’s name, voice, image, likeness, trademark, or brand is involved;
  • what ownership and reuse terms apply under the client agreement;
  • whether the intended market or channel introduces additional requirements.

Generated output should not be described as guaranteed to be free of third-party rights. Material intended for publication, commercial reuse, or transfer to a client receives the rights review appropriate to its risk and purpose.

12. Transparency About AI Use

The AI Transparency & Content Disclosure Statement governs when and how kōdōkalabs identifies direct AI interactions and discloses AI-generated or materially manipulated text, images, audio, and video.

Where a human-facing disclosure is required, it must appear clearly and accessibly at the point of interaction or exposure. A general policy page does not replace the local notice. The applicable treatment depends on the system, content, context, degree of AI involvement, kōdōkalabs’ role, human review, editorial responsibility, contract, platform, and law.

The transparency statement is separate from this ethics and safety statement because the two pages perform different functions:

  • this page describes the responsible-AI control environment;
  • the transparency page describes point-of-use disclosure decisions and labels;
  • the Privacy Policy explains relevant personal-data processing;
  • How We Work explains engagement roles, gates, documentation, and capability transfer.

13. Security and Misuse Prevention

Security controls must be proportionate to the use case, data, integration, and potential consequence. This public statement does not list confidential technical configurations.

The baseline policy requires that:

  • access is limited to people and systems authorized for the task;
  • credentials, authentication material, private keys, and secrets are not placed into unapproved AI tools or prompts;
  • integrations receive only the permissions needed for their approved function;
  • production actions, publishing, data changes, and external communications require the defined human approval;
  • safeguards, filters, logging, or access boundaries are not bypassed to obtain an output or accelerate delivery;
  • agent actions are tested in a controlled environment before production use;
  • untrusted instructions retrieved from webpages, files, messages, or tools are treated as data rather than authority;
  • suspected prompt injection, data leakage, unauthorized access, abnormal behavior, or control failure is escalated;
  • client and vendor security requirements are assessed for the actual workflow.

These policy requirements do not represent a claim that a particular encryption, monitoring, certification, testing, or incident-response technology is currently implemented. Verified technical controls should be described in controlled security documentation and client due-diligence materials.

14. AI Lifecycle Responsibilities

The precise contractual responsibilities are defined for each engagement. This table describes the operating model and is not a universal contractual allocation of liability.

Lifecycle stage
Accountable role
Required decision or evidence

Purpose and scope

Executive sponsor or business owner

Defined outcome, affected users, owner, boundary, and success criteria

Data and knowledge

Information owner and subject-matter expert
Classification, permission, source quality, access, and limitations

System selection

Workflow owner with technical, privacy, security, or legal input as required
Use-case suitability, vendor assessment, configuration, and approval

Design and build

kōdōkalabs engagement lead and implementation owner
Workflow map, controls, permissions, tests, and failure handling

Human review

Qualified reviewer and final approver
Evidence, quality, risk, transparency, and release decision

Deployment

Business owner and technical owner
Acceptance criteria, monitoring, rollback or correction path, and approval

Operation and measurement

Workflow owner
Performance, errors, user feedback, changes, and incident records

Handover and improvement

Client owner with kōdōkalabs support
Documentation, training, ownership transfer, and improvement backlog

15. Incident, Error, and Complaint Handling

An AI incident includes a material factual error, inappropriate or harmful output, unauthorized disclosure, suspected security event, rights concern, transparency failure, unexpected autonomous action, or control failure connected to an AI-enabled workflow.
Level
Example
Response direction

1 - Quality issue

Localized error with low consequence and no sensitive data or affected rights
Correct the output, record the cause where useful, and update the workflow if the issue could recur.

2 - Material content or operational issue

Published error, repeated failure, misleading claim, broken approval step, or material client impact
Pause the affected workflow, inform the owner, correct or withdraw the output, investigate the cause, and approve restart.

3 - Sensitive incident

Confidential or personal-data exposure, harmful output, deceptive media, unauthorized external action, or potential legal, security, or rights impact
Contain immediately, preserve relevant evidence, escalate to the policy owner and appropriate client, privacy, security, legal, or technical stakeholders, and assess notification duties.

4 - Critical incident

Ongoing or severe harm, systemic unauthorized action, material security compromise, or high-impact rights consequence
Stop the system or affected process where safely possible, activate the relevant incident process, involve qualified specialists and decision-makers, and do not resume without documented authorization.

The response sequence is: identify, contain, preserve evidence, classify, assign an owner, correct or mitigate, assess notification, investigate the root cause, approve restart, and update controls.

Notification decisions depend on the facts, contract, affected people, jurisdiction, and applicable law. This statement does not promise a universal response time or predetermine a legal notification obligation.

Questions, complaints, suspected omissions, and content concerns can be raised through Contact kōdōkalabs. Privacy concerns should also follow the route published in the Privacy Policy.

16. AI Literacy and Training

People should understand the systems they operate, the decisions they make, and the people who may be affected. Training is therefore assigned according to role, technical knowledge, experience, use context, and risk.

The proposed baseline requires:

  • all AI users to understand acceptable use, data classification, model limitations, source verification, transparency, and escalation;
  • workflow owners to understand permissions, integrations, failure modes, monitoring, and change control;
  • reviewers to understand the subject matter, evidence standard, risk factors, and authority to reject an output;
  • client-facing teams to understand confidentiality, contractual boundaries, and how to explain AI involvement accurately;
  • leaders and final approvers to understand accountability, risk acceptance, incident decisions, and applicable governance obligations;
  • training to be refreshed when systems, responsibilities, use cases, or regulation materially change.

Practical capability is developed through documented workflows, supervised use, review of real outputs, and recorded feedback—not only through general tool demonstrations. This supports the kōdōkalabs commitment to build client capability and transfer governed ownership rather than create permanent dependency.

17. Regulatory and Standards Alignment

This statement is informed by the current EU Artificial Intelligence Act — Regulation (EU) 2024/1689, including its provisions on AI literacy and transparency, and by the General Data Protection Regulation — Regulation (EU) 2016/679.

For Article 50-facing disclosures, kōdōkalabs also refers to the European Commission’s guidance on transparency obligations and [Code of Practice on Transparency of AI-Generated Content](https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content).

These references describe the legal and guidance baseline used to develop the policy. They do not mean that kōdōkalabs has received a certification, regulatory endorsement, conformity assessment, or legal determination of compliance. Applicability depends on the specific system, operator role, intended purpose, affected people, data, market, and deployment context.

18. Limitations

AI systems can produce incorrect, incomplete, biased, insecure, inconsistent, or contextually unsuitable output. They can misunderstand instructions, reproduce problems in source material, lose relevant context, and change after model or vendor updates.

Human review, data controls, evidence requirements, testing, access boundaries, and monitoring reduce selected risks; they do not remove every risk. A human-in-the-loop step is useful only when the reviewer has sufficient knowledge, authority, time, evidence, and visibility into the workflow.

No public statement can cover every client system, jurisdiction, industry, or future AI capability. Each material use case requires its own purpose, role, data, risk, and control assessment.

19. Related Policies and Guidance