Introduction: Can AI help us fight the problems it can also create?

Artificial intelligence is changing how people communicate, conduct business and manage information. It can help organisations analyse unusual activity, identify patterns, summarise security alerts and respond more quickly to potential threats.

However, the same technology can be misused to create convincing phishing messages, imitate trusted people, generate fraudulent documents and automate parts of a scam. The result is an increasingly complicated security challenge for organisations that may not have a dedicated IT department.

The UK Government's Cyber Security Breaches Survey 2025/2026 found that 43% of businesses and 28% of charities reported identifying a cyber breach or attack during the previous 12 months. Phishing was the most commonly reported type of incident. These figures relate to the survey's reporting period and the incidents respondents identified; they do not measure every attack that occurred.

The survey also found that among organisations using, adopting or actively considering AI, only around a quarter reported having cybersecurity practices or processes in place to manage risks associated with AI technology.

These findings suggest a practical challenge worth investigating: can affordable, accessible tools help small organisations recognise suspicious communications and establish safer ways to handle money, information and digital accounts?

The opportunity is not necessarily to invent a completely new AI model. It may be to combine existing technology, established cybersecurity practices and clear human procedures into a service that organisations can understand and use.

1. What is the problem we are trying to solve?

Cybersecurity covers many different threats, including account takeovers, ransomware, data theft, malicious software, fraudulent payments and unauthorised access to systems. A new business cannot realistically solve all these problems at once.

For a small organisation, the first challenge may be much more ordinary: receiving an email that appears to come from a manager, supplier, bank, funder or customer and deciding whether it is genuine.

A message might request an urgent payment, ask for a password reset, contain an unexpected attachment or claim that bank details have changed. Criminals may use personal information gathered online to make such messages more convincing.

AI-generated text can make suspicious messages more polished and may help criminals adapt their wording to particular recipients. Voice and image generation can introduce additional impersonation risks. However, not every scam uses AI, and AI alone does not explain the wider cybercrime problem.

The practical opportunity is to help people slow down, verify unusual requests through a separate trusted channel and follow consistent procedures before taking action.

Importantly, an AI tool cannot guarantee that a message is safe or fraudulent. A convincing message may be malicious, and a legitimate message may contain unusual wording. Human verification and established security controls remain essential.

2. Who needs a solution?

Potential customers include small businesses, charities, social enterprises, independent creative businesses, community organisations and professional service providers. These organisations may rely heavily on email, cloud storage, websites, social media, online payments and third-party suppliers.

The end users could include administrators, finance staff, managers, volunteers, freelancers and employees who do not have specialist cybersecurity training.

Potential buyers include business owners, charity trustees, operations managers, finance managers and IT providers. Potential partners could include managed IT service providers, cybersecurity consultants, insurers, local business networks, universities and organisations that support digital skills.

There is a distinction between a beneficiary and a paying customer. An employee might benefit from clearer security guidance, while their employer pays for training or software. A charity may need a low-cost service but have limited discretionary funding. A commercial service must establish who has the authority and budget to purchase it.

These questions should be answered through interviews and pilot testing rather than assumptions about what customers want.

3. Where could the opportunity work?

The initial market could be the UK, with a pilot focused on a specific group such as small charities, creative businesses or community organisations. A narrow starting point would make it easier to understand customers' workflows and evaluate whether the service is useful.

For example, a small creative company might receive messages about a music release, a collaboration, a booking, a rights payment or an urgent change to an invoice. A charity might receive a message requesting changes to supplier details or asking for sensitive information about a service user.

These examples illustrate possible scenarios, not evidence that either sector experiences a higher rate of attacks than other sectors. The founder should collect baseline information from the intended customers before deciding which market to serve first.

Delivery could initially take place through remote consultations, short workshops and a simple web-based demonstration. A later version could integrate with existing business systems if there is a clear need and the technical and privacy risks can be managed.

4. Why use AI at all?

AI can help summarise a suspicious message, explain common warning signs in plain English, identify inconsistencies for further checking and help an organisation develop staff training scenarios. It could also assist a qualified analyst in reviewing large volumes of security alerts.

However, some of the most effective protections do not require AI. Multi-factor authentication, passkeys, password managers, software updates, reliable backups, restricted permissions and verified payment procedures can reduce risk without needing a generative model to assess each message.

The National Cyber Security Centre's guidance for small organisations recommends practical measures to secure email and other important accounts, protect devices, maintain backups and recognise cyber attacks.

This creates an important commercial test: does adding AI improve the result enough to justify its additional cost, complexity and risk? If a checklist and a short training session solve the problem more reliably, that may be the better product.

5. The three solution ideas

Idea A: AI-assisted suspicious-message checker

The problem: Staff and volunteers may struggle to decide what to do when they receive an unexpected email, text or message asking for money, access or confidential information.

The proposed service: A tool that helps a user examine a message for warning signs, explains why further verification may be appropriate and provides a safe next-step checklist. It should direct users to verify requests independently rather than relying on the tool's judgement.

Why AI might help: A language model could summarise the message, explain suspicious features and make guidance easier to understand. A conventional rule-based checklist could provide much of the same value with fewer unpredictable outputs.

Existing alternatives: Email providers already offer spam and phishing protections. Security products, managed IT providers and free guidance from the NCSC also address parts of this problem. A new service would need to demonstrate a specific gap, such as accessible explanations, tailored organisational procedures or guided verification.

Minimum viable product: Start with a secure demonstration that uses synthetic messages and a documented checklist. Users can select a message type and receive an explanation of warning signs and suggested verification steps. Avoid automatic access to live inboxes at this stage.

Requirements and risks: Product design, web development, cybersecurity expertise, privacy advice, testing and clear disclaimers. Messages may contain personal data, confidential business information or malicious links. The product must avoid storing unnecessary content and must not automatically open links or attachments.

Potential income: A fixed-fee assessment, paid training package or subscription for organisations. These are hypotheses to test, not established revenue projections.

Why it might fail: Customers may prefer free tools, existing email protection may be sufficient, or AI may make mistakes that undermine trust. The product would need to prove that it improves users' decisions rather than merely producing convincing explanations.

Idea B: Fraud-resistant payment and identity verification service

The problem: Organisations may receive requests to change supplier bank details, approve urgent payments, reset accounts or disclose information while a message appears to come from a trusted person.

The proposed service: A simple verification workflow that requires additional checks for high-risk requests. It could provide payment-change procedures, approval records, staff prompts and reminders to contact the requester through a separately verified channel.

Why AI might help: AI could summarise requests, flag unusual language or identify missing information. However, the actual approval process should rely on defined rules, trusted contact records and authorised people rather than an AI model's confidence.

Existing alternatives: Accounting systems, banking controls, dual authorisation, identity-verification tools and established finance procedures already provide relevant safeguards. The opportunity would be to simplify their use for a particular group of smaller organisations.

Minimum viable product: A non-integrated prototype containing a verification checklist, a sample approval log and a procedure for confirming changes to payment details. Test it using fictional cases before considering integrations with financial systems.

Requirements and risks: Secure software design, finance-process expertise, access controls, audit records and appropriate legal advice. Payment information and identity data require careful protection. The product should not hold customer funds or initiate payments in its early versions.

Potential income: A one-off implementation service, annual licence or partnership with an IT provider. Willingness to pay and the savings generated would need to be measured.

Why it might fail: Organisations may already have strong payment controls, staff may bypass procedures under pressure, or integrations may be too costly. The service must make safe behaviour easier rather than adding excessive administrative work.

Idea C: Accessible cybersecurity training and simulation

The problem: Staff, volunteers and freelancers may not receive practical, accessible training on phishing, impersonation, account security and incident reporting.

The proposed service: Short workshops, accessible learning materials and optional simulated scenarios tailored to the organisation's work. AI could help generate different fictional examples and adapt explanations to different reading levels, with human review before publication.

Why AI might help: It may reduce the time needed to produce varied examples and plain-language explanations. A well-designed non-AI training package could still be effective, so the pilot should compare usefulness and cost.

Existing alternatives: NCSC guidance, Cyber Essentials resources, commercial training providers and managed IT companies already offer cybersecurity support. Differentiation could come from accessibility, sector-specific scenarios and practical organisational procedures, but these advantages must be tested.

Minimum viable product: A short training session, a set of fictional messages, a verification checklist and a follow-up questionnaire. Use no real passwords, genuine financial requests or deceptive live phishing tests during the initial pilot.

Requirements and risks: A trainer with appropriate cybersecurity knowledge, accessible content design, a secure evaluation process and permission from participating organisations. Scenarios should not shame participants or collect unnecessary personal information.

Potential income: Workshop fees, annual training packages, commissioned sessions or contracts with organisations supporting small businesses and charities.

Why it might fail: Training attendance may not translate into safer behaviour. Organisations may have limited budgets, and a generic course may not be sufficiently different from free resources. The service should measure behaviour and retention, not just satisfaction.

6. Comparing the three opportunities

The following scores are preliminary strategic judgements, not independent market research. Each criterion is scored from 1 to 5, with 5 representing the more favourable position. The scores assume a small founding team and a limited initial budget.

Idea A has strong potential for a scalable product but carries the risk that users may over-trust an AI-generated assessment. Idea B focuses on defined organisational procedures and could prevent costly mistakes, although implementation needs careful integration with existing processes. Idea C is the easiest to test without building complex software, but it may be harder to scale without developing repeatable materials and a sustainable delivery model.

Preliminary recommendation: Begin with Idea C, accessible cybersecurity training, and use it to validate the problems that Ideas A and B could later address. This approach allows a founder to learn from real users without initially handling live emails, sensitive inbox data or payment systems.

7. Recommended project: SafeSignal for Small Organisations

For the purposes of this investigation, the proposed working name is SafeSignal for Small Organisations. The name has not been checked for trademark availability or existing use and should not be treated as an established company or product.

The proposed service would combine accessible cybersecurity training with practical message-verification and payment-safety procedures. A later software component could support users in understanding suspicious messages, but only after the training-led approach has been tested.

Value proposition: Help small organisations build safer everyday habits through practical examples, understandable guidance and clear procedures for checking unusual requests.

Initial customers: A small group of charities, social enterprises or creative businesses that agree to participate in a pilot. No organisation should be described as a partner until it has explicitly agreed.

Delivery model: Begin with a paid or sponsored workshop and a short baseline assessment. Deliver the session, provide accessible materials and measure whether participants can better identify suspicious requests and explain how they would verify them.

Differentiator to test: Accessible explanations and tailored scenarios for organisations whose staff may have different levels of digital confidence. This is a proposed advantage, not a proven competitive gap.

Why start without an AI product? It is cheaper to test whether users need the service before developing software. If the training does not improve practical outcomes or organisations will not pay for it, the founder can stop or redesign the project without committing substantial funds.

8. Step-by-step implementation roadmap

First 30 days: Validate the problem

• Choose one initial customer group rather than targeting every type of organisation.
• Interview approximately 10–15 potential users or decision-makers, subject to recruitment and availability. This is a proposed discovery sample, not a statistically representative survey.
• Ask about recent suspicious messages, current security procedures, training gaps, existing tools and who controls the budget.
• Review existing free guidance and commercial alternatives to identify what is genuinely missing.
• Create a simple prototype using fictional examples, accessible materials and a verification checklist.
• Set a baseline assessment covering recognition of suspicious requests, knowledge of verification steps and confidence in reporting concerns.

Decision gate: Do not proceed to software development unless interviews reveal a specific problem, users demonstrate interest in testing a solution and there is a credible route to payment or sponsorship.

Days 31–90: Deliver a controlled pilot

• Recruit a small number of participating organisations through direct outreach or a suitable intermediary.
• Agree written pilot terms, privacy arrangements, accessibility needs and the evaluation process.
• Deliver the workshop and collect baseline and post-session results.
• Ask participants to complete fictional scenarios involving suspicious links, unexpected attachments, urgent payment requests and changes to supplier details.
• Measure whether participants choose safe verification steps and know how to report a concern.
• Interview decision-makers about usefulness, cost, implementation effort and willingness to purchase a second session.

Decision gate: Continue only if the pilot shows meaningful improvement against the baseline, participants can use the procedures in practice, and at least some prospective customers indicate a credible route to paying for the service.

Months 4–6: Refine and test commercial demand

• Revise the materials using pilot feedback and evaluation results.
• Develop a repeatable delivery manual, trainer checklist and standard evaluation report.
• Test a small number of pricing options with actual prospective buyers.
• Seek advice from cybersecurity professionals and review data protection, insurance, contractual and intellectual property requirements.
• Consider a lightweight digital resource library before building an AI-enabled checker.
• Investigate eligible grants and partnership opportunities using the project's actual scope and evidence.

Decision gate: Move towards software only if repeated customer feedback identifies a problem that software could solve better than training or existing tools.

Months 7–12: Decide whether to scale

• Seek repeat contracts or referrals from organisations that have completed the pilot.
• Build a simple secure prototype only if demand, technical feasibility and the business case justify it.
• Use synthetic or properly authorised test data and independent security review before handling real messages.
• Document limitations, escalation procedures, incident response and human review.
• Compare actual delivery costs and income with the financial assumptions.
• Decide whether to remain a training service, develop a software product, partner with an existing cybersecurity provider or stop.

9. Funding and partnership strategy

Public funding is not a general pot of money that any person can access simply by having an AI idea. Each programme has its own eligible applicants, project scope, technical requirements, deadlines, grant conditions and assessment process.

Route A: Bootstrap and validate first

The lowest-risk initial route is to develop a small training prototype, interview users and seek a modest paid pilot. A founder could use their own time and existing equipment, seek a commissioned workshop or explore a partnership with a suitable organisation.

This route is not guaranteed to generate income, but it can produce the evidence needed to judge whether a larger investment is justified.

Route B: Innovate UK — BridgeAI Deployment Catalyst: AI for Assurance and Compliance

At the research date of 29 October 2026, the official funding listing states that UK-registered SMEs can apply for a share of up to £5 million for the AI for Assurance and Compliance competition. The listed opening date is 21 October 2026 and the closing date is 8 December 2026 at 11:00 am UK time.

The programme concerns deployment of AI and machine-learning solutions that monitor, test, verify or evidence compliance with requirements, standards or controls. A basic phishing-awareness workshop would not automatically qualify. A developed AI-enabled assurance product might be relevant only if it meets the full competition scope and eligibility criteria.

The applicant must read the full competition brief, check eligible project costs and grant terms, and confirm whether the proposed work fits the programme before preparing an application. The published fund total is not an award to any individual applicant.

Official listing: BridgeAI Deployment Catalyst — AI for Assurance and Compliance.

Route C: Innovate UK — Frontier AI: SME Champions, Phase 1

The official competition listing states that UK-registered micro, small and medium-sized enterprises can apply for a share of up to £3.1 million for feasibility studies involving frontier AI and machine-learning technologies. The listed closing date is 11 November 2026 at 11:00 am UK time.

This is not a general grant for ordinary software development or cybersecurity training. A project would need a credible, technically ambitious frontier-AI research proposition and a clear route to scale. The proposed SafeSignal training service, as currently described, should not assume it is eligible.

Official listing: Frontier AI: SME Champions, Phase 1.

Route D: Cybersecurity procurement and future competitions

Innovate UK previously ran the Contracts for Innovation competition Cyber Scale in Critical Sectors, which closed on 10 June 2026. It is not an open application route at the time of this article. Its existence demonstrates that procurement-style competitions can support cyber solutions tested in real environments, but it does not mean a new award is currently available.

Monitor the UKRI funding opportunities and Innovate UK Innovation Funding Service for future competitions. Verify the status and full brief before making a funding plan around any new announcement.

Previous competition: Contracts for Innovation: Cyber Scale in Critical Sectors.

Potential partners

• Cybersecurity consultants and managed IT service providers.
• Small-business and charity support networks.
• Universities or research groups with cybersecurity and human-computer interaction expertise.
• Digital inclusion and accessible learning organisations.
• Accountancy and finance professionals who understand payment-control processes.
• Insurers or brokers interested in improving clients' cyber-risk practices.

These are categories of potential partners, not confirmed commitments. Any partnership should have a clear role, written agreement, appropriate safeguards and measurable objectives.

10. Financial and feasibility analysis

A responsible financial plan starts by separating a small training pilot from a software product. The first can be delivered with limited infrastructure; the second may require development, security testing, hosting, ongoing maintenance and specialist support.

Illustrative budget for a small training pilot

The following figures are planning assumptions only, not supplier quotations or evidence of market prices. They exclude VAT where applicable, founder salary beyond the time allowance, and any significant custom software development.

Actual costs may fall outside these ranges depending on staffing, professional rates, accessibility requirements, insurance arrangements and the number of pilot organisations. Obtain quotations and define the work before committing money.

Software development is a separate investment

A secure AI-enabled message checker could require substantially more expenditure. Costs may include product design, secure development, model or API usage, hosting, access controls, privacy assessment, testing, monitoring, incident response and independent security review.

No precise software budget is given here because the technical design, integrations, data flows and required assurance level have not yet been defined. The sensible next step is to establish those requirements and obtain comparable estimates from qualified developers.

Commercial model

Possible income models include a fixed workshop fee, a commissioned training programme, a repeat annual service or a subscription to a future software tool. Prices should be tested with real prospective customers.

For example, if a founder charged an illustrative £400 for a workshop and delivered four workshops in a month, gross revenue would be £1,600 before preparation time, travel, taxes, insurance, marketing and other costs. This is a mathematical scenario, not a forecast or evidence that customers will pay that fee.

Commercial viability depends on repeat demand, delivery costs, customer acquisition, the ability to maintain quality and whether the service solves a problem customers value enough to purchase.

11. Risks, safeguards and failure conditions

AI reliability

An AI system may wrongly classify a malicious message as safe or a legitimate message as suspicious. The product must not present an AI output as a guarantee. It should explain uncertainty, direct users to independent verification and provide a clear route to human support.

Data protection and confidentiality

Emails and messages may contain names, contact details, financial information, confidential business records or sensitive personal data. The project should minimise collection, define retention periods, restrict access and avoid sending confidential content to third-party AI services without appropriate assessment and authorisation.

Before processing personal data, determine the relevant data-protection roles and lawful basis, review the provider's data handling, and assess whether a data protection impact assessment is required. Seek qualified advice where necessary.

Cybersecurity

A tool intended to improve security could itself become a target. Apply secure development practices, access controls, encryption where appropriate, vulnerability testing, dependency management, backups and an incident-response plan. Never ask users to paste passwords, authentication codes or payment credentials into the tool.

Accessibility and fairness

Guidance should be understandable to people with different levels of digital confidence and different communication needs. Avoid assuming that spelling, grammar, disability or unfamiliarity with technology indicates suspicious behaviour. Test materials with intended users and provide alternative formats.

Legal and operational boundaries

Do not build features that access accounts without permission, collect credentials, conduct unauthorised security tests or automatically make financial decisions. Live phishing simulations should not be introduced without suitable authorisation, safeguards and a clear purpose.

When to stop or pivot

• Stop if prospective users do not identify a meaningful problem or there is no credible buyer.
• Redesign if the training does not improve measured knowledge or behaviour.
• Do not develop software if existing tools already meet the need at lower cost.
• Pause if privacy, security or safety risks cannot be adequately managed.
• Consider a partnership rather than building a new product if an established provider can deliver the same outcome more reliably.

12. How will we measure success?

The pilot should establish a baseline before training and measure results immediately afterwards and again after an agreed follow-up period, such as six to eight weeks.

These are proposed pilot thresholds, not industry standards. They should be agreed before data collection and adjusted to the setting and sample size. A small pilot can show whether a service is promising, but it cannot establish that the product prevents cybercrime across the wider population.

Where feasible, an independent evaluator should review the design and results. The project should report negative findings as well as positive results.

13. Conclusion: What should happen first?

AI-assisted cybersecurity is a real area of innovation, but the most credible opportunity for a new founder may not be to build a sophisticated detection engine. It may be to address a specific and measurable gap in how small organisations recognise, verify and report suspicious requests.

The evidence shows that cyber incidents affect businesses and charities, with phishing remaining a common reported threat. It does not establish that a new AI product will succeed commercially. That question must be answered through customer research, controlled testing and a realistic financial plan.

The recommended starting point is an accessible training and verification pilot. It is relatively straightforward to test, can use fictional data and provides a way to learn directly from potential customers. If evidence later supports a software product, the founder can develop it with appropriate technical expertise, privacy protections and independent security review.

The founder's conclusion

There is a credible problem to investigate, but not yet a proven business. The founder should first interview prospective users, test existing alternatives and run a small pilot. Significant software expenditure should wait until the need, buyer and value proposition are clearer.

The funder's conclusion

A funder should look for a defined user problem, evidence of demand, a technically credible approach, measurable outcomes, a realistic budget and a responsible plan for data protection and cybersecurity. A grant application should match the actual scope and eligibility conditions of the programme; the existence of an AI or cyber funding announcement is not sufficient.

Recommended first action: Prepare a one-page pilot proposal and interview 10–15 prospective users or decision-makers. Use their evidence to decide whether to proceed, redesign or stop before committing significant funds.

Sources and further reading

• UK Government — Cyber Security Breaches Survey 2025/2026, published 30 April 2026.
• UK Government — Cyber Security Sectoral Analysis 2026, published 12 May 2026.
• National Cyber Security Centre — Small organisations guide to cyber security.
• National Cyber Security Centre — Phishing attacks: defending your organisation.
• UKRI — BridgeAI Deployment Catalyst: AI for Assurance and Compliance.
• UKRI — Frontier AI: SME Champions, Phase 1.
• Innovate UK — Contracts for Innovation: Cyber Scale in Critical Sectors, closed 10 June 2026.
• Cabinet Office — PPN 014: Cyber Essentials Scheme.
• UK Government — Data and AI Ethics Framework.
• Information Commissioner's Office — Guidance on AI and data protection.