Hiroshi.TEditor
Before a small business enters a customer enquiry, property viewing note or staff record into an AI service, it needs to know where that information goes and what the service is allowed to do with it. The correct starting point is not a supplier's reassuring privacy slogan. It is a recorded decision about the data, purpose, account configuration, access rights and actions that the proposed workflow requires. This guide distinguishes an ordinary drafting assistant from an AI connection with access to live business systems, then sets out the checks an owner can actually perform.
The UK's Information Commissioner's Office (ICO) AI guidance distinguishes legal requirements from recommended good practice and warns that guidance is under review following the Data (Use and Access) Act. The National Cyber Security Centre (NCSC) secure AI system development guidelines, published in November 2023, cover design, development, deployment and operation. The second document is principally guidance for AI-system providers and integrators, not a certificate that a product used by a business is secure. Together they give a useful way to ask evidence-based questions of vendors.
1. Establish precisely which information enters the AI
Begin with a data map for the proposed task, not a general label such as 'office documents'. An estate agent preparing a public listing description might use authorised room dimensions and marketing particulars. A colleague preparing a landlord update might instead hold names, telephone numbers, viewing feedback and information about an individual's circumstances. Those inputs have different sensitivities and permissions. Identify the original record, its owner, the people represented, the purpose of processing and whether the same result could be produced from less information.
Test data minimisation in practice. Can a system classify an enquiry using only the subject and a redacted description? Must a person's full address, contact history or identity document be included? Some tasks work with reference codes, limited excerpts or approved templates. However, simply removing a name may not render information anonymous if other details identify the person. Ask the organisation's responsible data-protection contact to assess the actual information flow rather than treating a cosmetic redaction as proof of safety.
2. Check the actual supplier terms and account settings
Different products, service tiers and account configurations can impose different rules for retention, training, human review and onward disclosure. Check the documentation applying to the exact account the firm will use. Determine whether the supplier acts as a processor, a controller or another party for each processing activity; whether a data-processing agreement is appropriate; where personal data may be transferred; and what deletion or export is possible when the contract ends. Do not assume a business subscription automatically prevents every form of provider use.
Ask whether conversations and files are stored, how long they remain accessible, who at the supplier may review them, whether sub-processors are involved and how policy changes are communicated. Check whether the settings are controlled centrally or can be altered by individual staff. The answers should be documented with the relevant vendor policy version and review date. A marketing page calling a product 'private' is not a substitute for this evidence.
3. Separate what the AI can read from what it can change
For an isolated assistant, a user might manually supply one authorised file and receive a draft. A connected system may search a shared drive, read email, inspect a CRM, create tasks and send messages. This expands both the quantity of information exposed and the consequences of a mistake. List each connector, its permission scopes, whether it acts as the user or as a service account and what happens if a user has access to more than one property branch or client portfolio.
Give a trial account only the records and capabilities necessary for its task. Test a normal request and a request for information the operator is not meant to see. Test an attempted write to a restricted record, a deleted account and an expired integration token. A model should not bypass permissions enforced by the source system. Where actions affect a customer's money, booking, contact details or legal position, use human approval and deterministic application checks rather than allowing generated text to function as authority.
4. Treat generated instructions and retrieved text as untrusted
AI systems can be influenced by instructions embedded in material they analyse. A malicious website, document or email could contain text trying to redirect the assistant, disclose confidential content or alter the task. For a property office, an inbound enquiry should be treated as a customer's message, not an administrator's instruction to change the CRM. The application must distinguish trusted business rules from untrusted content, even if both arrive in readable language.
Where an assistant can call tools, restrict the available operations, validate inputs, authenticate the requester and confirm high-impact actions outside the model. Avoid connecting a browsing or document-reading assistant to unnecessarily powerful write access. Check logs for unusual retrievals and attempted actions. These controls sit alongside, not instead of, conventional security measures such as multi-factor authentication, patch management, tested backups and separation of staff roles.
5. Decide whether a DPIA and other assessments are needed
When personal data is processed, the organisation must identify its lawful basis and meet applicable data protection obligations. A data protection impact assessment is required for processing likely to result in high risk to individuals; it is not automatically required for every low-risk text draft. The ICO's explanation of its AI guidance directs organisations to assess their actual risks and obligations. Record why a DPIA is or is not required and review that conclusion if the purpose, dataset or degree of automation changes.
For a proposed tenant-screening or customer-profiling process, the risk may be materially different from generating generic marketing copy. Consider fairness, accuracy, transparency, automated decision-making and the possibility that output could adversely affect an individual. Do not use an AI tool to make a consequential decision merely because it returns a confident classification. Those responsible for regulated or legally sensitive activities should obtain qualified advice about the specific workflow.
6. Test failure, correction and the exit route before rollout
Security cannot be judged from a successful demonstration alone. Run test cases involving a wrongly attached document, a duplicate enquiry, a misleading source file, a revoked user's request and an unavailable supplier service. Confirm whether the system blocks the action, flags uncertainty or passes the case to a staff member. For connected systems, check that a failed operation does not leave one database updated whilst another still displays an old state. The person responsible must be able to correct the record and explain what happened.
Define retention and deletion tests as well. Can staff remove stored conversations through the agreed route? Can an administrator revoke connector access? Can the firm export its records and return to a manual workflow if the tool is withdrawn? Incidents should have a contact, triage rule and reporting route. The NCSC lifecycle guidance emphasises operation and maintenance, including logging and monitoring; a supplier's security posture is not permanently settled at the moment of purchase.
7. Write a short policy people can actually follow
A practical approved-use policy names the permitted tools, allowed data types, forbidden inputs, review responsibilities, access owners and escalation contacts. It should tell a property employee, for example, that an approved assistant may help draft a public description from verified particulars but must not receive identity documentation or send tenancy communications without the designated workflow and permission. It should also address whether staff can use personal accounts or install unapproved browser extensions. Make the rules accessible at the point of work.
Run a narrow pilot before broad adoption. Record the tool version, account settings and source data, then test quality, permissions and corrections with a small set of representative cases. Give staff a route to report an unsafe or inaccurate output without pressure to conceal it. Review the policy when a new integration, dataset, supplier or use case is introduced. The point is not to promise zero risk; it is to make information exposure, responsibility and corrective action visible before any serious failure occurs.
Further reading and scope: ICO, about AI and data protection guidance (legal and good-practice distinction; under review); NCSC, Guidelines for secure AI system development (27 November 2023). This is practical operational guidance, not a legal determination, penetration-test report or assurance of a named vendor's security.