Security and governance

Useful AI, without turning the business into a black box.

AI tools can create risks including data leaks, privacy breaches, unreliable outputs and supply-chain exposure. AiBorz treats security, ownership and operating controls as part of the product, not a paragraph at the end.

Security principles

Practical rules before AI gets near real data or real customers.

No broad-access agents. No hidden automations. No uncontrolled customer-facing AI.

Business dataClient-owned systems where practical
AccessLeast privilege
Customer-facing outputHuman approval unless explicitly approved
Sensitive dataNot used in unapproved tools
RecordsLogs for important AI actions
Risky actionsEscalate to humans
Failure modePause, review, rollback
Monthly governanceIncluded in managed AI ops

Client-owned accounts

Systems should run inside client-owned Microsoft, Google, OpenAI, cloud and SaaS accounts where practical.

No personal AI accounts

Staff should not use personal ChatGPT accounts or random AI tools for business data.

Least privilege

AI only gets the access it needs for the approved workflow.

Human approval

AI should not send, delete, purchase, refund, approve, publish or alter key records without approval unless the risk is low and explicitly authorised.

Data minimisation

Only send the minimum data needed to complete the task.

Approved tools only

Every AI tool should be approved, documented and owned by the business.

Logging and monitoring

Important AI actions, failures, costs and exceptions should be logged and reviewed.

Kill switch

Workflows must be easy to pause or disable.

No black box

The client receives documentation, system maps, operating procedures and admin access where practical.

AiBorz AI Doctrine

The operating rules we build around.

  1. Humans remain accountable. AI can assist, recommend, draft and automate, but a named person remains accountable.
  2. Start with low-risk, high-value work. Automate repetitive admin before complex judgement.
  3. No sensitive data in unapproved tools. Staff must not paste customer, employee, commercial or confidential data into personal tools.
  4. Every AI system needs an owner. Each system needs a purpose, allowed data, allowed actions, escalation path and success measure.
  5. Human approval is required for material actions. Important customer messages, commitments, critical records, payments and external publishing need appropriate approval.
  6. AI use should be transparent where it matters. Customers and staff should be told when AI meaningfully affects them or could reasonably be mistaken for a human interaction.
  7. AI must be tested before launch and monitored after launch. No workflow should go live without testing, failure examples, escalation rules and monitoring.
  8. The client owns the system. The client should own accounts, data, documentation, prompts, workflows and operating procedures wherever practical.
  9. Security beats novelty. No AI feature is worth deploying if it creates unreasonable privacy, security, legal or reputational risk.
  10. AI is not always the answer. Sometimes the right answer is a better process, cleaner data, simpler automation or staff training.

Agent access levels

Most business systems should stay at Level 1-3 until the controls mature.

Level 0No business dataGeneral draftingSafe starting point
Level 1Read-only approved dataSearch internal policy docsGood early use case
Level 2Drafting onlyDraft customer email, staff approvesRecommended for most SMEs
Level 3Limited write accessUpdate CRM note after approvalUse with controls
Level 4Autonomous actionSend email, book job, refund customerAvoid unless mature
Level 5Critical system controlFinance, payroll, legal, health, safetyDo not use without advanced governance

Policy pack

Every implementation should leave the client operationally safer.

AI Acceptable Use PolicyWhat staff can and cannot do with AI.
Approved AI Tools RegisterApproved tools, owners, use cases and risk levels.
AI System RegisterEach workflow, purpose, data access, owner, tool, controls and review date.
Data Classification GuideWhat data can be used in which systems.
Use Case Risk AssessmentRates each use case before build.
Vendor Assessment ChecklistPrivacy, data storage, training use, access and security.
Human Review SOPWhen staff must check or approve AI outputs.
Incident Response ProcessWhat happens if AI leaks data, hallucinates or acts unexpectedly.
Monthly AI Ops ReportUsage, risks, improvements and incidents.
AI Safety Hub — practical guidance for staff

In production

What these systems will not do.

Most AI companies brag about capability. We document restraint. Every production system has explicit hard limits — and that is the trust signal.

No autonomous Pipedrive mutationsMarketplaceBot scans 450 deals daily. It cannot delete, archive or change a single record without explicit approval.
No salary data to unauthorised peopleFinanceBot handles Employment Hero data for 174 employees. Salary and remuneration access is restricted to 4 named individuals.
No NZ invoices into Australian XeroFinanceBot checks entity separation on every invoice before forwarding. Cross-entity errors are prevented at the routing level.
No unsupported API workaroundsAirwallex receipt upload is not automated because the API does not support it yet. FinanceBot reports the limitation instead of building a risky workaround.
No sending without approvalEvery customer-facing, financial or external action requires human approval during warm-up. The first 100 outputs are reviewed.
No broad access agentsEvery production bot has scoped permissions, approved tools, and documented boundaries. No "connect to everything" shortcuts.

For the full operating model behind these limits, see the access ladder and the controlled launch protocol.