Published by SundAI
A useful project starts with a problem your team can describe. Use this guide to choose the service that fits, understand the package boundaries and prepare a proposal your decision-maker can assess. Tell us what needs to work better; we will help turn it into a focused brief.
Updated · SundAI
| Service | Start here when | Useful outputs | Entry-package boundary |
|---|---|---|---|
| Compliance, GRC & AI Governance | AI responsibilities are unclear or customers need coherent compliance evidence. | An AI/data map, prioritised gaps, an action plan, up to three document drafts and handover. | One organisation, one process or product, one framework and up to ten control areas. Certification, legal opinions and a DPO appointment are excluded. |
| Secure AI Business Automation | A repeated business process needs fewer manual handoffs and clearer controls. | A workflow specification, scoped integrations, validation, approvals, failure handling and handover. | One workflow, up to two systems with documented APIs, one trigger, one environment and two refinement rounds. Missing APIs, major migrations and unrestricted consequential actions are excluded. |
| Private AI Assistants, Agents & RAG | Users need answers from your knowledge, with permissions and traceable sources. | A permission-aware assistant pilot, source citations, scoped controls, evaluation and handover. | One assistant, one ready knowledge source, one interface, one cloud, up to two roles and ten pilot users. Actions need explicit scope; multi-cloud, extensive OCR and production availability commitments are excluded. |
| OSINT, Pentesting & Red Teaming | You need to examine an authorised web/API attack path and prioritise fixes. | Rules of Engagement, protected evidence, prioritised findings, a report, handover and one included-fix verification within 30 days. | One small web app, up to two roles and ten API endpoints. Broad red teaming, phishing, load tests and destructive testing are separate. |
| DevSecOps & Secure Delivery Pipelines | Your route from code to release needs better checks, permissions and approvals. | A focused threat model, code/dependency/secret checks, pipeline identity controls, release gates and recovery guidance. | One repository, one pipeline, one deployment target and up to two environments. Platform migration is excluded; extra checks and supply-chain features require agreement. |
| Cloud Security Engineering, Automation & Maintenance | Selected cloud identities, permissions, configuration and security signals need review. | A permissions map, licensing-dependent access controls, audit logging, up to five alerts, emergency-access guidance and a treatment plan. | One subscription, account or project, up to ten identities and ten selected resources. Multi-cloud, a complete SOC, emergency availability and a response SLA are excluded. |
Choose a private assistant and RAG pilot when authorised users need answers grounded in your documents. Choose secure automation when a defined event should move information or complete a process across systems. Retrieval and actions can be combined, but each action, permission and approval must be scoped.
Choose governance for applicable requirements, evidence gaps, responsibilities and a readiness plan. Choose a pentest to investigate authorised technical targets and prioritise fixes. A pentest is useful evidence; it does not replace a governance programme or establish compliance.
Choose DevSecOps for repository checks, pipeline identities, release gates and recovery guidance. Choose cloud security for selected identities, resources, configuration and audit signals in one account or project. Agree the handoff if a deployment pipeline also needs cloud permissions changed.
Bring the answers you have. Unanswered questions are part of the discovery conversation, not a reason to write a vague contract.
Name the process, product, repository or cloud account; list targets, interfaces, environments and exclusions. Record deliverables, refinement or retest limits and how additional work is approved.
Identify what data enters each provider, model endpoint, knowledge store and log. Agree access, supplier data-use terms, hosting region, retention and deletion. European service delivery does not by itself establish where every supplier processes data.
Name the business owner, technical contact, change approver and risk decision-maker. Provide authorised access and a contact for stopping tests or handling failures. Define which actions need human approval.
Choose representative inputs and observable checks. Agree what happens with unavailable systems, denied access, uncertain answers or repeated events. Record cost estimates, budgets or caps, external licences and the person who approves changes.
Agree which configuration records, test evidence, runbooks and access-transfer steps your team receives. Record remaining risks, maintenance ownership and separately required support. An entry project does not automatically include continuous monitoring or an availability SLA.
A general promise to be secure or useful is hard to assess. Select checks tied to the agreed scope, representative data and your operating constraints. The examples below can start that discussion.
These public references help buyers ask better questions about AI risk, secure software development and application verification. They provide context; their inclusion is not certification, accreditation or evidence that a particular project has passed every control.
YOUR NEXT MOVE / SUNDAI
Bring one task, one system or one question. We’ll start there.
One focused conversation. A clear scope. No obligation.
