The integration is usually a small part of the code and a large part of the risk. The model is a service you call, and what you send, trust and do with the answer decides the outcome.
We name no client and claim no result. Providers are treated neutrally, and each provider's own documentation governs its terms.
Step 1: Pick one feature and a baseline
Choose a feature where AI would help a user or staff member and where a wrong answer is cheap to catch: summarizing a long record, drafting a reply, classifying an incoming item, searching internal documents. Write what the task costs today in time and errors so you can compare. Our AI implementation plan covers the wider stages.
Step 2: Choose a pattern
Most integrations use one of four patterns. Start with the simplest that does the job.
- A direct model call. Your back end sends text to a model through its API and uses the reply. Good for summarizing, classifying and drafting.
- Retrieval first. Your code looks up relevant passages from your own data, then sends them with the question so the model answers from them. Good for questions about your documents.
- Tool use. The model can request actions, such as looking up an order, and your code runs them. Good for tasks with a few well-defined steps.
- An agent. The model chooses its own steps and tools. Reserve it for open-ended problems.
Anthropic's post Building effective agents (19 December 2024) advises finding the simplest solution possible and increasing complexity only when needed, and notes that agentic systems often trade latency and cost for better task performance. See our guides to how to build an AI agent and AI workflow automation.
Step 3: Decide what data may leave your systems
List the data the feature needs and what must never be sent. Terms differ by provider and plan. OpenAI's data guide says that, as of 1 March 2023, data sent to its API is not used to train or improve its models, that abuse-monitoring logs are kept for up to 30 days by default, and that zero data retention is available only to customers it approves (read 12 November 2026). Other providers have their own terms, so read the ones for your plan and record them.
Send only what the task needs, remove or mask personal data where you can, and keep records of what was sent. If the feature touches regulated data, such as health or financial information, ask a lawyer and your security team before you build.
Step 4: Treat model input and output as untrusted
A model reads whatever you give it, including text written by users or found in documents, and that text can try to steer it. OWASP's prompt injection page (LLM01:2025) says inputs can alter a model's behavior in unintended ways, and lists mitigations: restrict the model's access privileges to the minimum necessary, use human-in-the-loop controls for privileged operations, and separate untrusted content. It says it is unclear whether there are fool-proof methods of prevention. So validate what comes back before your code acts on it, never let the model hold secrets or run actions you would not give an anonymous user, and require a person to approve anything that matters.
Step 5: Build it so it can fail safely
- A switch. Put the feature behind a flag you can turn off at once.
- A fallback. Decide what the user sees if the model is slow, down or returns something unusable. The old path should still work.
- Timeouts and limits. Cap how long you wait and how much you spend per request and per day.
- Logs. Record the input, the version of the model and prompt, the output and what your code did, with sensitive data handled according to your policy.
- A clear label. Tell users when a result is machine-generated, and let them correct it.
Step 6: Test before and during use
Build a test set of real examples with known good answers, including awkward and hostile ones, and run it each time you change the prompt, the model or the data. NIST's AI RMF 1.0 (January 2023) says AI systems should be tested before their deployment and regularly while in operation. After launch, read a sample of real outputs every week, and track corrections and complaints, not only usage.
Step 7: Plan for model changes
Models are retired and replaced. Anthropic's deprecations page says it regularly retires older models, that applications may need occasional updates, that impacted customers are notified, and that it gives at least 60 days' notice before retiring a publicly released model; it advises testing replacements well before the retirement date. Other providers set their own schedules. So pin the exact model version in your configuration, record it in your inventory, keep your test set ready to run on a replacement, and give one person the job of watching notices.
Step 8: Measure and widen carefully
After a few weeks, compare against the baseline: time saved, errors caught, corrections made, complaints, speed and cost per request. Include the cost of building and reviewing. If the result is clearly better, widen use one step at a time. If not, change the design or stop. Our guide to measuring digital marketing ROI uses the same logic for marketing work.
Where does help fit?
Many teams can add a simple model call themselves. Help is useful when the feature touches several systems, when the data is sensitive or regulated, when you need tests and controls designed in, or when you want a second view of the design. Our AI integration page covers connecting models to systems, our API integration page covers the connections themselves, and our AI consulting page covers planning.
Conclusion
Integrating AI well means one feature, the simplest pattern, clear rules on data, untrusted input handling, a safe failure path, real tests, version tracking and measurement.
PromotEdge International is an international strategy, technology, marketing and design company, and our delivery team is in India. See our AI integration page. For definitions, see our glossary entry on APIs.
Facts we rely on: see our company facts for what we state about ourselves and where each fact comes from.