keelz

Data security

Use AI safely, with every step auditable

Every workflow we build carries these four safeguards. They are not a paid extra.

01 No leaks02 A person approves03 Quality checks04 Reversible

For IT and procurement — jump straight to a section

Where data sitsTechnical controlsAI risksPDPASub-processorsIncidentsStandardsVendor review docs
DataChecksHumanLog
01

Your data does not leak

We map your data before any work starts — tap a tier to see where it is allowed to go.

  • Data sorted into 3 tiers before a line of code is written
  • Sensitive tier: masked, or run on your own server
  • NDA on day one · contracts bar training on your data
The Private LLM service
02

A person approves every point that matters

AI does the heavy lifting, people decide — switch the approval off in the graphic and see what happens.

  • Approval points: pricing, discounts, payments, complaints
  • Approve from your phone, with the full reasoning attached
  • Anything the AI is unsure about goes to a person automatically
03

Quality rules before anything ships

Every workflow has a checklist you signed off on — turn it off in the graphic to see what slips through.

  • Numbers must match the source — price, total, tax, stock
  • Answers from documents must cite them; if nothing is found, it says so
  • A monthly report of the % sent back
How we measure, with a sample report
04

One step at a time always reversible

There is no day when one switch changes the whole company — it opens stage by stage; tap through them here.

  • We move up a stage when the numbers say so, not when we feel like it
  • Your team holds the off switch; work goes back to the old way at once
  • The code, the data and the vendor accounts are yours

What it actually looks like

One piece of work and everything it passed

Approval requestWaiting on manager
CustomerRungrueang Materials Co., Ltd.
Items3 items · 540 units
Net totalTHB 88,400
Discount over the 10% cap · 1 unpaid invoice on file
ApproveEdit firstSend back
Quality checks8 checks · 1 failed
  • Price matches the latest price file
  • Total and tax are correct
  • Every figure traces back to a system
  • 12% discount is over the 10% cap
Passed automatically94%
Sent to a person6%
Activity logEvery job, replayable
  1. 09:12AI

    Drafted quote #4821 from the customer chat

  2. 09:13System

    Ran 8 checks — 1 failed, sent to a person

  3. 09:14Human

    Manager approved — discount changed 5% → 3%

  4. 09:14System

    Emailed and logged to the CRM

Mock example (names and numbers invented) — the real one is built around your business

In writing

Not just a promise that it is safe — there is something to inspect

NDA from day one

A DPA on top, in whatever form your legal team wants

A written data map

Which job uses which tier, and what it passes through

Access to the logs

Your team looks back on its own, without asking us

All of it belongs to you

Code, documents, data, vendor accounts

Need a stricter standard than this — see the enterprise page

Where the data sits

Three ways to set it up — you choose how far data travels

No single option fits every company. This is the table your IT team needs to decide from — the trade-offs both ways, stated plainly.

Cloud model via API

Your system calls an outside provider's model, with sensitive data masked before anything goes out.

Best for: Businesses that want to start fast, on work that still functions once the data is masked.

Runs in your own cloud account

The whole system is installed in your account and VPC. keelz works inside the access you grant, and you can take it back at any time.

Best for: Companies with an IT team and a cloud account already in use.

On your own servers (Private LLM)

A model installed on your organisation's own machines. No data leaves your network at all — details at /services/private-llm

Best for: Companies whose rules forbid data leaving, and who can invest in the hardware.

Data that leaves your company

Cloud model via API
Only masked text goes out
Runs in your own cloud account
Stays in your account, except model calls
On your own servers (Private LLM)
Never leaves your company

Where the data sits

Cloud model via API
The model provider's data centre
Runs in your own cloud account
Your account/VPC, you pick the region
On your own servers (Private LLM)
Machines inside your organisation

Who holds the accounts and keys

Cloud model via API
Keys issued from your own account
Runs in your own cloud account
You hold both the account and the keys
On your own servers (Private LLM)
You hold it all, keelz enters as allowed

Connecting to internal systems

Cloud model via API
Only through the APIs you expose
Runs in your own cloud account
Can connect inside the same network
On your own servers (Private LLM)
Connects to internal systems directly

Upfront cost

Cloud model via API
Lowest, pay for what you use
Runs in your own cloud account
Medium, cloud cost sits on your bill
On your own servers (Private LLM)
Highest, hardware before you start

Time before you go live

Cloud model via API
Fastest of the three
Runs in your own cloud account
Medium, cloud account is set up first
On your own servers (Private LLM)
Longest, hardware then installation

Data sensitivity it suits

Cloud model via API
General data, and data you can mask
Runs in your own cloud account
Internal data and customer data
On your own servers (Private LLM)
Confidential and PDPA-sensitive data

Dependence on outside vendors

Cloud model via API
High, tied to the model provider
Runs in your own cloud account
Medium, providers can be swapped
On your own servers (Private LLM)
Low, open models on your machines

You can switch later — many companies start with the first option on low-risk work, then move anything touching personal data in-house.

Technical controls

A list your IT team can tick off line by line

Standard on every project, not a paid add-on — anything tagged “planned” is something we have not finished yet, and we say so here instead of staying quiet.

Encryption

Data is encrypted on the wire and on disk, and is never written to a log in readable form.

  • Encrypted in transitTLS 1.3

    Every channel runs on HTTPS/TLS 1.3. Old protocol versions and unused ports are turned off.

  • Encrypted at restAES-256

    Disks, databases and backup files are all encrypted with AES-256.

  • No sensitive data in logsMasked before writing

    ID card numbers, phone numbers, addresses and bank account numbers are masked before anything is written to a log or sent to error tracking.

  • Masked before it leaves

    When a cloud model is called, anything that identifies a person is replaced with a reference code before it leaves your system, then swapped back when the answer returns.

  • Certificates and expiry datesAuto-renewed

    TLS certificates renew automatically, with an alert ahead of time if a renewal fails.

System access

Who can reach what is named person by person, and can be taken back the moment a job ends.

  • Only the access the job needsleast privilege

    We work on least privilege. The team gets access to the specific systems and environments a job needs, never full admin by default.

  • One account per personNo shared accounts

    Everyone uses their own account. No shared accounts and no shared passwords, so every action traces back to a person.

  • Two-factor authenticationIn progress

    The goal is MFA on every account that reaches a customer system — cloud, code repositories and working tools. It is not yet enforced on every account.

  • Access reviewed each quarterIn progress

    The system already builds a full access report every quarter (who can log in, who can read keys, which keys have gone unrotated). The step where an owner checks and signs it off is not yet running on a schedule.

  • Access pulled when a job or a person endsWithin 1 business day

    Accounts are closed and every key revoked within 1 business day of the job ending or someone leaving the team.

Keys and secrets

Keys and passwords never sit in the code, are split per environment, and can be changed without touching the system.

  • Secrets live outside the repoNever in git

    Keys and passwords sit in a secret manager or in that environment's variables. They are never in a code file.

  • A separate key per environmentdev/prod split

    dev, staging and prod use different keys. A dev key cannot reach real data.

  • Keys rotated on cycle and on any eventRotated on any event

    Keys change on the agreed cycle, and immediately when someone leaves the team or a key is suspected of leaking.

  • Secret scan before every deployStops the build

    The standard deploy script scans the whole tree before each build. A .env file, a provider key or anything that looks like a secret in the source stops the build on the spot.

  • Secrets handed over one way onlyExpiring links

    No passwords or keys over chat or email. Only a password manager, or a link that expires by itself.

Keeping environments and data apart

Experiments never touch the real thing, and one customer's data never mixes with another's.

  • dev / staging / prod kept apart3 separate tiers

    Different machines, different databases, different keys. A change in dev has no path to real data.

  • No real data during developmentMasked data

    Development and testing run on masked or synthetic data. If real data is unavoidable it is approved case by case and deleted when the work is done.

  • One store per customerNo mixing across customers

    Each project has its own storage and its own permissions. One customer's data is never used for another.

  • Agents see a fixed scope

    An agent sees only the data sets and tools named in that job. Widening it means changing the configuration, with an approver.

  • Team machines set up to one standardDisk encryption

    Disk encryption, automatic screen lock, and no customer data files kept on personal machines.

Logs and the audit trail

Everything an agent does leaves a trace you can check later, and you can open it yourself without asking keelz.

  • Every agent action is loggedaudit log on everything

    We record who asked, what they asked, when, which source documents were used, and what was answered.

  • You can open it yourselfAdmin screen

    There is an admin screen on your side. Search and filter by user, time range and action type, and export to a file.

  • Logs cannot be editedappend-only

    Logs are append-only. Nobody can edit or delete a past entry, not even the keelz team.

  • Kept for the period we agree90 days by default

    90 days by default, extendable to your requirements, with how long they are kept and when they are deleted written into the contract.

  • Alerts on unusual patternsAutomatic alerts

    Thresholds are set in advance — unusually frequent calls, large data pulls, or use outside working hours — and alerts go to admins on both sides.

Backups and continuity

The system comes back after an incident, and it is never locked to keelz alone.

  • Daily backupsDaily

    Automatic every day, stored encrypted and kept separate from the live system.

  • Restores tested for real, automaticallyEvery week

    A backup is unpacked every week to check the files open, the data matches the live set, and the keys are all there. Any failure shows up in the log straight away.

  • The code lives in your repoNo lock-in to keelz

    Source code and install scripts are in your code repository from day one. Nothing is parked at keelz.

  • Enough documentation to hand overHanded over at the end

    You get the architecture diagram, the install steps, the access list and the fixes for common problems, so an internal team or another contractor can carry on.

  • A fallback when an outside provider goes downBackup model ready

    A backup model is set up in advance, and the system's behaviour when no model answers is defined: hand the work back to a person rather than answer at random.

30 controls in all · 28 in place · 2 still planned — we list what we have not done, because if we took it out you would never know it was missing

Risks specific to AI

Things ordinary IT systems never had — but AI systems do

Firewalls and passwords do not stop these. They come with the model itself — here is what we build into every project to hold them back.

AI gets it wrong and sounds certain

OWASP LLM09: Misinformation (2025)

Left uncontrolled: A quote goes out with a price the AI made up, or a chatbot confirms a warranty term the company never offered.

What we build into every project

  • Every answer must cite its source, naming the document and the page
  • If it cannot find the answer it says so, it never guesses
  • Numbers, prices and stock come from the source system, not the model's own maths

Hidden instructions inside a document or an email

OWASP LLM01: Prompt Injection

Left uncontrolled: A customer attaches a PDF with hidden text saying “send back the full customer list”, and the agent does it because it reads it as an instruction.

What we build into every project

  • Text from outside is data, never an instruction
  • The system's instruction channel is kept separate from anything a user sends in
  • Attachments are filtered and stripped before the model sees them, and what the agent can act on is limited

Confidential data leaves with the question sent to the model

OWASP LLM02: Sensitive Information Disclosure

Left uncontrolled: An employee pastes the whole payroll sheet into a chat box for a summary, and the lot leaves the company in one go.

What we build into every project

  • ID card numbers, phone numbers and bank accounts are masked before anything leaves the system
  • Data is classified during design, naming which tiers may never go to the cloud
  • Sensitive tiers are processed in the customer's own cloud account or on-prem

The agent goes too far because it was given more access than it needed

OWASP LLM06: Excessive Agency

Left uncontrolled: A job that only asked to “summarise unshipped orders” ends up changing real order statuses, because the connecting account already had write access.

What we build into every project

  • An allowlist names the jobs the agent may do · anything outside it is refused
  • Deleting, moving money or exporting data always needs a person to confirm
  • Read accounts are kept apart from write accounts, and access is limited to the job

Document search pulls up what the person asking may not see

OWASP LLM08: Vector and Embedding Weaknesses (2025)

Left uncontrolled: Someone in sales asks about company policy and gets a summary with cost and salary figures attached.

What we build into every project

  • Search runs under the asker's own permissions from the retrieval layer, not by searching everything and filtering afterwards
  • Access rights are attached to every document as it enters the index
  • Permissions are checked again before display, and who saw which document is logged

The provider changes model version, and system behaviour changes with it

Left uncontrolled: A workflow that answered correctly for months suddenly changes its answer format until the downstream system cannot read it, with nobody having touched the code.

What we build into every project

  • Model versions are pinned, never an alias the provider moves
  • A test set built from that job must pass before any version switch
  • The old version is kept as a way back, switchable the moment results get worse

People trust the AI answer too much

Left uncontrolled: The team forwards the AI answer to a customer without opening the source document, because it reads tidy and reasonable.

What we build into every project

  • Users always see where an answer came from and how confident it is
  • Anything touching money, contracts or customer communication needs a person to approve it first
  • The real users are trained at handover on what to trust and what to check

The system or the provider goes down, and the work stops with it

Left uncontrolled: The model provider has an afternoon outage, and order intake that moved entirely to AI comes to a halt with no fallback way to work.

What we build into every project

  • Every job has a manual way back, written into the handbook
  • Designed so model providers can be swapped, never tied to one
  • A kill switch per workflow, so only the part with the problem is turned off

PDPA

Who is responsible for what — written down before we start

In law you are the personal data controller and we are the processor acting on your instructions. This table is what goes into the data processing agreement (DPA).

Set the purpose and the lawful basis

Your side (controller)
You decide what is collected, what for, and on which basis
keelz side (processor)
We process only what your instructions and the DPA allow

Notify data subjects / collect consent

Your side (controller)
You publish the privacy notice and collect consent yourself
keelz side (processor)
We build the notice and consent points using your wording

Records of processing activities (RoPA)

Your side (controller)
You keep the controller-side RoPA and keep it current
keelz side (processor)
We keep the processor-side RoPA + give you our data map

Put appropriate security measures in place

Your side (controller)
You set the sensitivity tiers and access inside your company
keelz side (processor)
Encryption in transit and at rest · split access · audit logs

Answer data subject requests (DSAR)

Your side (controller)
You take the request, verify identity, answer within 30 days
keelz side (processor)
We search, export, edit or delete on instruction, in 7 business days

Report a personal data breach

Your side (controller)
You notify the PDPC within 72 hrs · notify subjects if high risk
keelz side (processor)
We tell you within 24 hrs, with the scope, evidence and logs

Using sub-processors

Your side (controller)
You approve the list, and object to any you cannot accept
keelz side (processor)
We name them in advance and bind them to the same terms

Delete or return the data when the work ends

Your side (controller)
You choose return or deletion, and receive the final data set
keelz side (processor)
We return in the agreed format, then delete in 30 days + written confirmation

How long we hold the data, and when it goes

Real data used for testing / sample documents

Stored where
keelz-managed dev machines, a separate space per project
Held how long
Only during that project's build and UAT
Deleted when
Whole set deleted once UAT passes · masked data where possible

Data flowing through the workflow in production

Stored where
Your own source and target systems · keelz keeps no copy
Held how long
Per your own systems' retention policy
Deleted when
Deleted on your systems' cycle · keelz has no copy to delete

Prompts and answers sent to the model

Stored where
The model provider via API · nothing kept permanently at keelz
Held how long
The provider's temporary window (named in the annex)
Deleted when
Auto-deleted at the end of that window · contractual no-training terms

Audit logs of what the agent did

Stored where
Your systems, or a server keelz runs for you
Held how long
90 days to start, adjustable to your requirements
Deleted when
Rotated out automatically at the end of the set period

Files users upload into the system

Stored where
File storage in your own cloud account by default
Held how long
The file lifetime agreed when the work was designed
Deleted when
Deleted on the set policy, or immediately when you say so

Contact details of system users and admins

Stored where
Your permission system · keelz keeps only what it needs to coordinate
Held how long
For the life of the service contract
Deleted when
Deleted within 30 days of the contract ending

Backup copies

Stored where
Encrypted backup storage, separate from the live system
Held how long
Overwritten on the backup cycle, no more than 30 days
Deleted when
Cannot be deleted one by one · expires on cycle after the live copy goes

Written into the contract: your data deleted within 30 days of the project ending with proof of deletion sent to you — backups expire on the cycle listed in the table

For the work we build for you, the contracting party and the data processor in law is CODELAB STUDIO CO., LTD. (บริษัท โค้ดแล็บ สตูดิโอ จำกัด) — “keelz” is a brand of that company; the name on the NDA and the data processing agreement (DPA) is always the registered one.

If your customers exercise their PDPA rights

01

You take the request and verify identity

The data subject files the request with you as the data controller. You check who they are and identify which right they are exercising.

02

You send keelz a written instruction

Send it through the channel named in the DPA, with the identifying details, the right being exercised and the systems involved. keelz never acts without an instruction.

03

keelz searches and does the technical work

We go through every system we run for you, then export, edit, suspend or delete as instructed. Normally done within 7 business days of a complete instruction.

04

We hand you the result and the evidence

A summary of which systems held the data and what was done, with the supporting logs, so you can answer the data subject inside the deadline the law sets.

Sub-processors

Who else sees your data

The question procurement always asks — we answer before it comes. The actual list for your project is an annex to the contract, and we tell you before any of it changes.

Anthropic (Claude)

Used for
Main model for reading, summarising and drafting in most work
Sees what
Only the prompt and documents each workflow run sends in
Processed in
United States
No training on your data
In the contract
If you say no
Switch to another model, or run a Private LLM on your machines

OpenAI

Used for
Backup model, plus specific jobs such as speech to text
Sees what
Only prompts and files sent to the API
Processed in
United States
No training on your data
In the contract
If you say no
Can be turned off · use Claude or Gemini for the same job

Google (Gemini)

Used for
Long documents, and work that connects to Google Workspace
Sees what
Prompts, documents and files sent to the API
Processed in
The region chosen for that project
No training on your data
In the contract
If you say no
Can be turned off · swap to another model with similar results

Cloud / server provider

Used for
Runs the workflow apps and databases keelz manages for you
Sees what
All the data that system stores (encrypted at rest)
Processed in
Singapore or Thailand, agreed per project
No training on your data
In the contract
If you say no
Move it into your own cloud account, or on-prem

Email / notification provider

Used for
Sends the alert emails and reports the agent produces
Sees what
Recipient address, subject line and the content sent out
Processed in
Depends on the provider chosen for that project
No training on your data
In the contract
If you say no
Use your own mail server, or notify through LINE/Teams

File storage provider

Used for
Stores attachments and the documents the agent creates as it works
Sees what
Uploaded files and output files (encrypted at rest)
Processed in
Singapore, or your own account
No training on your data
In the contract
If you say no
Point it at storage in your own account or network

Error tracking tool

Used for
Catches system errors so we fix them before the work stalls
Sees what
Error messages and metadata · personal data stripped out
Processed in
Depends on the provider chosen for that project
No training on your data
No specific clause
If you say no
Can be turned off · use logs on your own server instead (slower fixes)

When something goes wrong

No one can promise it never happens — we can promise what we do next

A company that says “it cannot happen here” is a company with no plan. This is what we commit to in the contract.

  1. 1As soon as it is reported

    Take the report and confirm it is real

    Reports arrive through the incident channel named in the contract, or from the system's automatic alerts. The named responsible person decides whether it counts as a security incident, and the clock starts at that confirmation.

  2. 2Within 4 hrs of confirmation

    Contain the damage before investigating the cause

    Revoke the keys and accounts involved, hit the kill switch on the affected workflow, cut connections to the customer's systems as far as needed, and keep the logs as evidence before changing anything.

  3. 3Within 24 hrs of confirmation

    Tell the customer with whatever is known so far

    We are bound in writing to tell the customer within 24 hours of confirming an incident: what happened, which systems and data we believe are affected, what has been contained, and what is still unknown. We do not wait for the investigation to finish. If it counts as a personal data breach, we hand the customer, as the data controller, what they need to notify the PDPC within 72 hours under PDPA.

  4. 4Within 3 business days

    Fix it and bring the system back into use

    Close the hole, rotate every key and password involved, restore from backup if needed, then bring workflows back one part at a time while watching the results, with the order agreed with the customer first.

  5. 5Within 14 days

    Report the cause and the permanent fix

    A written report with the timeline, the real root cause, the confirmed scope of impact, the permanent fixes and a due date for each, plus a review meeting with the customer's team.

The commitment, as a number: we tell you within 24 hours of confirming a real incident, with whatever we know at that point. We do not wait for the investigation to finish — and the contract names the person you can call directly.

Standards we work from

We use global frameworks as checklists — and we say plainly that we are not certified

keelz is not certified against ISO 27001 or SOC 2 and we will not word anything to suggest we are. What we do is take the control lists out of those standards and use them as a design checklist on every real project. If your organisation requires certified vendors, we say on the first call that we do not meet that bar — better than you finding out when internal audit asks.

Personal Data Protection Act B.E. 2562 (PDPA)

We follow it

The Thai law that applies directly to our work. We act as a data processor on the customer's instructions, with a data processing agreement, records of processing, support for data subject rights, and deletion of the data within 30 days of the work ending.

OWASP Top 10 for LLM Applications

Used as a checklist

The checklist we run over every AI build before it goes live. We go item by item to show how that build blocks prompt injection, data leaks and more access than the job needs. Anything not relevant gets a written reason.

NIST AI Risk Management Framework (AI RMF 1.0)

Used as a checklist

The thinking frame we use during design: what risks this job carries, how they are measured, and who is responsible. It puts the scope and the human approval points in writing from the start, instead of after something goes wrong.

ISO/IEC 27001 Annex A

Not certified

We use the Annex A control list as the starting point for what we cover: access management, encryption, key handling, logging and managing sub-processors. keelz has not been audited against ISO 27001 and holds no certificate.

ISO/IEC 42001 (AI management systems)

Not certified

A management system standard for organisations that build or use AI. We take its guidance on impact assessment, naming who is responsible, and reviewing a system after it goes live, and apply it to our delivery process. keelz has not been audited and holds no certificate.

The checklist we actually use

Personal Data Protection Act B.E. 2562 (PDPA)

What this standard is

The Thai law that sets how far an organisation may collect and use personal data, what reasons it needs, and what rights the data subject has.

How we use it

We work as a processor on your instructions. This checklist is run before every project, and answered again whenever a project's data scope changes.

  1. 1

    Name the lawful basis for every data set the AI touchesSections 24 and 26

    We go through each data set to state which basis it runs on, and mark clearly which sets are sensitive data needing explicit consent.

  2. 2

    Map the data flow before development starts

    You get your project's data flow map in the first week: where the data starts, which systems it passes through, what leaves the company, and where it is masked before being passed on.

  3. 3

    Sign the DPA before touching the first real data setSection 40

    The draft DPA sets the scope of processing instructions, the data types, how long it is kept, the use of sub-processors, notice of an incident within 24 hrs, and deletion within 30 days. Your own template can be used instead.

  4. 4

    Keep processor-side records of processing activitiesSection 40

    We hold the processor-side RoPA for that project, and give it to you as support for the controller-side RoPA you keep yourself.

  5. 5

    Strip out data the job does not use before it enters the workflow

    Only the fields the workflow actually needs are pulled. ID card numbers, phone numbers and bank accounts are replaced with reference codes before they leave your system.

  6. 6

    Send the sub-processor list for approval before use

    We say in advance which providers are used, what data each one sees, which region processes it, and whether there are contractual no-training terms. Anything you object to, we swap out.

  7. 7

    Walk a real DSAR route end to end before going liveSection 30

    A sample request is pushed through all 4 steps to prove we can search, export, edit and delete in every system we run for you, within 7 business days of a complete instruction.

  8. 8

    Set a retention period and a deletion method per data setSection 37 (3)

    Every data set in the lifecycle table has an owner, a retention period and a deletion method. Your data is deleted within 30 days of the work ending, with written confirmation.

  9. 9

    Name the destination country and the basis for sending data abroadSections 28 and 29

    The contract annex states which provider processes in which country, and which lawful basis for cross-border transfer supports it.

  10. 10

    Name the responsible people and the incident channel in the contractSection 37 (4)

    Once an incident is confirmed we tell you within 24 hrs, with its scope and the logs, so you can notify the PDPC inside the 72-hour window as the controller.

Limits you should know

PDPA is a law to follow, not a certificate to hold, and we have never been checked by an outside assessor, so this checklist is a self-assessment. Several duties under the law are yours as the data controller and we cannot do them for you: publishing the privacy notice, collecting consent, appointing a DPO, and notifying the PDPC within 72 hrs. The wording and the timeframes on this page should be confirmed by your own legal counsel or DPO before you rely on them in a contract.

Want it as a file for your IT team? Ask for the vendor review pack.

The checklist we actually use

OWASP Top 10 for LLM Applications

What this standard is

The 10 vulnerabilities found most often in applications built on language models, put together by the OWASP security community.

How we use it

Run item by item against every AI build before it goes live, with the answers written down. Anything not relevant to the job needs a written reason, never a blank.

  1. 1

    Keep system instructions separate from incoming contentLLM01: Prompt Injection

    Text and attachments from outside are data, not instructions. Attachments are filtered and stripped before the model sees them, and what the agent can act on is limited.

  2. 2

    Mask personal identifiers before they leave your systemLLM02: Sensitive Information Disclosure

    ID card numbers, phone numbers and bank accounts are replaced with reference codes before going out, then swapped back when the answer returns. Sensitive tiers are processed in your account or on-prem.

  3. 3

    Pin the model version and check where libraries come fromLLM03: Supply Chain

    No alias the provider can move, library versions locked, and a sub-processor list stating what data each provider sees.

  4. 4

    Confirm we neither train nor fine-tune models ourselvesLLM04: Data and Model Poisoning

    Our work uses off-the-shelf models through an API, with contractual no-training terms. This risk is therefore limited to the RAG document store, which is controlled by vetting what goes into it.

  5. 5

    Check the output format before passing it downstreamLLM05: Improper Output Handling

    Model answers are schema-checked before being written to a database or passed on. Model text is never assembled into a command a downstream system runs directly.

  6. 6

    Limit what the agent can do with a per-job allowlistLLM06: Excessive Agency

    Anything outside the list is refused, read accounts are kept apart from write accounts, and deleting, moving money or exporting data always needs a person to confirm.

  7. 7

    Keep no secrets in the system promptLLM07: System Prompt Leakage

    Keys, passwords and confidential business terms live in a secret manager or on the server side, never in the text sent to the model.

  8. 8

    Search under the asker's permissions from the RAG retrieval layerLLM08: Vector and Embedding Weaknesses

    Access rights are attached to every document as it enters the index, checked again before display, and who saw which document is logged.

  9. 9

    Require a cited source, and no guessing when nothing is foundLLM09: Misinformation

    Every answer names the document and the page. If nothing is found it says so. Numbers, prices and stock come from the source system, not the model's own maths.

  10. 10

    Cap the call rate, and alert on anything unusualLLM10: Unbounded Consumption

    Call rate and request size are limited per user, thresholds alert on unusually frequent calls or large data pulls, and every workflow has its own kill switch.

Limits you should know

This is a review by the team that built the system, not an assessment by an outside reviewer. We do not offer penetration testing and we do not claim any test results. Prompt injection is tested with a sample set before go-live and whenever a model version changes; we do not yet run red teaming on a schedule. OWASP also revises the list edition by edition, so when the list changes this checklist will lag until the next review round.

Want it as a file for your IT team? Ask for the vendor review pack.

The checklist we actually use

NIST AI Risk Management Framework (AI RMF 1.0)

What this standard is

The AI risk management framework from the US National Institute of Standards and Technology, split into 4 functions: GOVERN, MAP, MEASURE, MANAGE.

How we use it

Used as the question set during design. The answers for all 4 functions go into the scope document from the start, instead of being worked out once something goes wrong.

  1. 1

    Name who is responsible for the system, on our side and yoursGOVERN

    The contract names who decides on scope, who receives an incident report, and who approves a change, because we do not run a 24/7 monitoring team.

  2. 2

    Write down what the AI may do, and what it must notGOVERN

    The jobs the agent may do are listed, with the points that need a person to approve before anything goes out: anything touching money, contracts or customer communication.

  3. 3

    Walk this project through the list of 8 risksMAP

    The risk list on this page is the starting point. We state which of them can happen on this job, what the damage would be, and which control covers it.

  4. 4

    Name who is affected when the AI gets it wrongMAP

    Identify the people at the end of the line, such as a customer sent the wrong quote or an employee judged on an answer, then set the remedy before go-live.

  5. 5

    Have a test set for that job, and a bar it must passMEASURE

    The test set is built from your real work. It must pass before go-live and before every model version switch, and it is handed over with the system so your team can run it.

  6. 6

    Measure from the logs after go-live, not from impressionsMEASURE

    The audit log records who asked, what they asked, which source documents were used and what was answered. Your admins can open it and export it themselves.

  7. 7

    Have a kill switch per workflow and a manual way backMANAGE

    Every job has a manual way of working written into the handbook, only the part with the problem is switched off, and the previous model version is kept for an instant switch back.

  8. 8

    Have an incident procedure with the timeframes set in advanceMANAGE

    Confirm the incident, contain it within 4 hrs, tell you within 24 hrs, restore within 3 business days, and send the root cause report within 14 days.

  9. 9

    Review the risks again whenever the scope changesMANAGE

    Adding a data source, adding access or changing model version all count as a change of scope, and mean running the checklist again before reopening.

Limits you should know

AI RMF is voluntary. There is no assessment scheme and no certificate to hold. We use it as a question set at project level, not as an organisation-wide profile the way the document suggests, and we do not work through every subcategory because many are written for organisations that build their own models. All of it is assessed by our own team, with no outside reviewer checking it again.

Want it as a file for your IT team? Ask for the vendor review pack.

The checklist we actually use

ISO/IEC 27001 Annex A

What this standard is

The international standard for information security management systems. Annex A is the control list organisations use as a starting point for what they need to cover.

How we use it

We put the Annex A list next to the 30 technical controls stated on this page to find what is not covered yet, then close it before the work starts. It is a self-assessment, not an assessment by anyone else.

  1. 1

    Give only the access the job needs, never full admin by defaultA.5.15 Access control

    We work on least privilege. The team gets access only to the systems and environments a job needs, and the table of requested access goes to your IT team to cut before anything is opened.

  2. 2

    Access pulled in 1 business day · quarterly access report generated automaticallyNot done yetA.5.18 Access rights

    Accounts are closed and keys revoked within 1 business day when a job ends or someone leaves, and an access report is generated automatically each quarter. The step where an owner checks and signs it off is not yet running on a schedule.

  3. 3

    An account per person, never shared · MFA not yet enforced everywhereNot done yetA.5.17 Authentication information

    Everyone uses their own account and nobody shares passwords, which is already the case. Enforcing MFA on every account and every tool is not complete yet.

  4. 4

    Encrypt both in transit and at restA.8.24 Use of cryptography

    Every channel runs on TLS 1.3. Disks, databases and backup files are encrypted with AES-256, with certificates renewed automatically and an alert if a renewal fails.

  5. 5

    Keep keys outside the repo, split per environment, and scan before deploy

    Keys are always outside the source, dev and prod use different keys, keys rotate the moment a leak is suspected, and a scanner stops the build automatically if a secret gets into the tree.

  6. 6

    Keep audit logs that cannot be edited, and alert on anything unusualA.8.15 Logging and A.8.16 Monitoring activities

    Logs are append-only, kept 90 days by default with the deletion date named in the contract, and thresholds alert admins on both sides on unusually frequent calls or large data pulls.

  7. 7

    Keep dev / staging / prod apart, and no real data in developmentA.8.31 Separation of development, test and production environments

    Different machines, different databases, different keys. Development runs on masked or synthetic data; if real data is unavoidable it is approved case by case and deleted when the work is done.

  8. 8

    Bind sub-processors to the same terms we give youA.5.19 Information security in supplier relationships

    We name them in advance, state what each one sees and which region it sits in, bind them on the same terms, and leave room for you to object to any you cannot accept.

  9. 9

    Back up daily, and test a real restore every weekA.8.13 Information backup

    Automatic daily backups stored separately from the live system, plus a weekly test that unpacks a backup to prove it restores, not just that the file is there.

  10. 10

    Have an incident procedure written before an incident happensA.5.24 Information security incident management planning and preparation

    The 5 steps and timeframes stated on this page, with the responsible people named, the incident channel, and containment ordered before the investigation into the cause.

Limits you should know

keelz has not been audited against ISO/IEC 27001 and holds no certificate. This checklist is a self-assessment against Annex A headings only. It is not a certification and it is not a Statement of Applicability. We have not set up a full management system as the standard's main clauses require: no declared ISMS scope, no organisation-level risk assessment, no internal audit and no management review. The clause numbers are there so your IT team can check them further, and where we were not sure which heading applies we left the number out.

Want it as a file for your IT team? Ask for the vendor review pack.

The checklist we actually use

ISO/IEC 42001 (AI management systems)

What this standard is

A management system standard for organisations that build or use AI, covering who is responsible, impact assessment, and reviewing the system across its working life.

How we use it

We take parts of its guidance into our delivery process, so every project has an owner, an impact assessment before it starts, and a review round after it goes live.

  1. 1

    Assess this project's impact on the people affected, before starting

    Name who is affected by the system's answers, what the worst outcome would be, and which kinds of work we turn down because the risk is too high to control with process alone.

  2. 2

    Name the owner of the AI system, on our side and yours

    The contract states who approves a change, who is told when an answer goes wrong, and who can order a workflow shut off.

  3. 3

    Write the intended use, and the uses that are not allowed

    State what the system was designed for and what it must never be used to decide, written into the handover manual where the real users can see it.

  4. 4

    Set the points where a person must approve before the system acts

    Deleting, moving money, exporting data and communicating with customers always need a person to confirm, with the sources behind the answer shown to the approver first.

  5. 5

    Tell end users they are using AI, and how far to trust it

    The screen shows where each answer came from and how confident it is, and we train the real users at handover on what to trust and what to open the source document for.

  6. 6

    Handle a model version change as a written procedure

    The version is pinned, never an alias the provider moves. The test set must pass before a switch, and the old version is kept as a way back that switches over instantly.

  7. 7

    Keep a register of the models and providers each project actually uses

    List the providers, the region that processes the data, what each one sees, and which have contractual no-training terms, along with the option to switch each one off.

  8. 8

    Review the results after go-live on the cycle we agree

    A review is booked after launch: read the audit log for where answers missed and what users keep correcting by hand, then adjust the workflow or narrow what the AI does.

  9. 9

    Take complaints about output through the same channel as incidents

    Users can challenge an answer through the channel named in the contract. Everything is logged and answered, rather than being a verbal remark that disappears.

Limits you should know

keelz has not been audited against ISO/IEC 42001 and holds no certificate. What we do is take parts of its guidance into our delivery process, not set up a full AI management system across the company. We have no formally published organisation-level AI policy, no objectives measured in numbers, no internal audit or scheduled management review, and no regular red teaming, only before each project goes live. We do not put the standard's clause numbers here because we have not checked them one by one against the document itself.

Want it as a file for your IT team? Ask for the vendor review pack.

When IT reviews a vendor

The pack we send without being chased

If your organisation has a vendor review process, we have been through it many times — tell us what you need and we will have it ready.

  • Your security questionnaire, filled in by us

    Send your company's form and we fill it in, in writing. Where we do not have something or cannot do it, we say we do not, and name what we use instead. We do not answer just to get through.

    Before signing

  • NDA and a draft data processing agreement (DPA)

    A DPA drafted under PDPA, setting the scope of processing instructions, the data types, how long it is kept, the use of sub-processors, notice of an incident within 24 hrs, and deletion within 30 days of the work ending. Your own template can be used instead.

    Before signing

  • A data flow map for your project

    Where the data starts, which systems it passes through, what leaves the company, what stays on your machines, where it is stored, for how long, and at which point it is masked before being passed on.

    First week of the project

  • Architecture diagram and sub-processor list

    The architecture for your project specifically, with the providers actually used: what each one sees, which region processes it, whether there are contractual no-training terms, and which ones you can switch off.

    First week of the project

  • The access we ask for, with a reason for each line

    A table of every system and permission we request: read or write, what it is used for in the job, who on our team holds it, and when it is returned or revoked. Your IT team can cut anything unnecessary before opening access.

    Before access is opened

  • Handover pack and a manual for the next team

    Code, diagrams, configuration, the test set, how to kill a workflow, how to rotate keys, and the manual way of working when the system is down. Written so an internal team or another contractor can take over without us.

    At handover
Request the vendor review packEnterprise requirements

FAQ

The worries we hear most

Will our customer data be used to train models?

No. We pick providers whose contracts state plainly that usage data is never used for training, and sensitive-tier data is masked before it is sent — or processed on your own server instead.

What if the AI gets it wrong and it reaches a customer?

Every workflow is checked before anything goes out, and anything touching money or a customer needs a person to approve it. Work that fails a check, or that the AI is unsure about, goes back to a person instead of being guessed at. Every step is logged, so you can see exactly where it went wrong.

Do we have to move data out of our current systems?

No. We connect to what you already use (LINE, Sheets, ERP, accounting software) and ask only for the access that job actually needs. Your database stays where it is.

Where does PDPA come in, and who is responsible?

You are the data controller; we are the processor acting on your instructions. That is why we map the data and set the lawful basis before any work starts, keep the data to what is needed, and delete sample documents when the project ends.

If we want to stop, what happens to the data and the system?

You switch it off and work goes back to the old way without touching your existing systems. The code, the documents and the data have been yours from the start, and the support package can be cancelled any month.

Still worried about something? Just ask

A free 30-minute call. We tell you straight what will work, and what your business should not do yet.

Book a free 30-minute callFrequently asked questions

You do not have to take our word for it — open the live system and look The real approval queue, with work sitting there until a person decides — nothing reaches a customer until someone does (sample data, no login).

Free consultation

Book a free call 30 minutes