Home •Blog
TTMS Blog
TTMS experts about the IT world, the latest technologies and the solutions we implement.
Sort by topics
SaaS validation in pharma and GxP requirements
A SaaS application can support quality processes, laboratory work, manufacturing, distribution or clinical operations without requiring the customer to maintain the application in its own data centre. The cloud delivery model does not remove the regulated company’s responsibility for the way the system is used. If an application processes GxP data, affects product quality or patient safety, or supports regulated decisions, the organisation must demonstrate that it is fit for its intended use and remains controlled throughout its lifecycle. SaaS validation in pharma differs from a conventional implementation project. The supplier controls part of the platform, releases updates on its own schedule and may rely on subcontractors. The customer configures processes, roles, data, integrations and use. Responsibilities are shared, but regulatory accountability for the GxP process remains with the regulated organisation. This guide explains when a SaaS system requires validation, how to build a risk-based strategy, which supplier evidence can be used and how to maintain the validated state through frequent software releases. It focuses mainly on GMP environments. Many of the principles can also support GLP, GCP, GDP and pharmacovigilance systems after the applicable regulations and company procedures have been identified. 1. What SaaS validation means in a GxP environment Computer system validation provides documented evidence that a system meets approved user requirements, performs according to its intended use and is controlled in proportion to risk. In a SaaS model, the object of validation is not the supplier’s product in isolation. It is the customer’s specific use of the application, including its configuration, processes, data, interfaces, user roles and operating procedures. The same product may have a different validation status in two companies. One may use it only to arrange meetings. Another may use it to approve specifications, retain laboratory results or generate a record used in batch release. The product name and supplier claims do not determine the validation scope. Intended use, data criticality and the effect of each function on the regulated process do. In practical terms, the validation programme should answer four questions: Are the business and regulatory requirements clear and approved? Have risks to patients, products and data integrity been identified and controlled? Have the configuration and critical processes been tested effectively? Can the organisation maintain control after go-live? Validation is not a permanent certificate attached to an application. It is an evidence-based state associated with a defined version, configuration and use, and maintained through change control, incident management, access management and periodic review. 2. When a SaaS system falls within GxP scope The first step should be system and function classification, rather than ordering a full set of test scripts. The organisation needs to determine whether the application creates, modifies, stores, transfers or reports data used in regulated activities. It must also consider whether a failure, configuration error or unauthorised change could affect product quality, patient safety, data reliability or process compliance. SaaS applications that may have GxP relevance include: electronic quality management systems and eQMS platforms; document management, learning and training systems; LIMS, ELN and analytical data management platforms; clinical operations, safety and case management applications; systems for change control, deviations, CAPA and complaints; ERP, planning and warehouse systems when their data affect GxP operations; electronic record and signature platforms used in regulated processes. Not every function in such a system has the same criticality. A document approval workflow may require more rigorous controls than a supporting dashboard. A risk-based approach directs testing and documentation towards the functions that affect protected records and regulated decisions. 2.1 GxP impact assessment The impact assessment should identify the regulated process, business owner, record types, decisions made from the data and possible consequences of failure. A single GxP or non-GxP label may be too broad for a system that supports several processes. Function-level and data-flow analysis produces a more defensible scope. Functions are likely to have higher impact when they: control a critical process step or provide data used to release it; generate, calculate or approve a result relevant to product quality; retain original data, metadata and the audit trail; manage electronic signatures or approvals; transfer data between systems without an independent completeness check. The outcome should identify critical requirements, the evidence required and the types of change that will trigger reassessment or regression testing. 3. Regulatory basis for pharmaceutical SaaS validation The primary European reference is EudraLex Volume 4 and EU GMP Annex 11. Annex 11 applies to computerised systems used in GMP-regulated activities. It requires applications to be validated and IT infrastructure to be qualified. Decisions about validation scope and data-integrity controls should be based on a justified and documented risk assessment. Annex 11 does not create a separate legal class for SaaS. The delivery model does not remove obligations relating to supplier assessment, validation, security, audit trails, business continuity, archiving and periodic evaluation. The current EudraLex listing identifies the January 2011 revision of Annex 11 as the applicable published text. EMA guidance on GMP and data integrity expressly includes cloud-based applications and storage within the data lifecycle. An organisation should understand where data and metadata are generated, processed, transferred, stored, retrieved and disposed of, and which parties can access them. Validation effort should be scaled to risk. ICH Q9(R1) on quality risk management states that the level of effort, formality and documentation should be commensurate with risk. This principle does not allow required controls to be reduced for budgetary reasons. It allows evidence to be tailored to function criticality, system complexity and uncertainty. GAMP 5 is widely used as industry guidance for applying a lifecycle and risk-based approach to GxP computerised systems. The ISPE overview of GAMP 5 describes a framework intended to support systems that are effective, reliable and fit for use. GAMP 5 is not legislation and does not certify a product. Each organisation still needs a validation strategy based on applicable regulations, intended use and its pharmaceutical quality system. Where a system supports activities regulated in the United States, the scope of 21 CFR Part 11 and the relevant predicate rules also needs to be assessed. FDA guidance on electronic records and electronic signatures explains that Part 11 applies to specified electronic records maintained or submitted under FDA requirements. Not every electronic function is automatically in scope, and a claim that software is Part 11 compliant does not replace an assessment of the configured process. 4. Responsibilities of the regulated company and SaaS supplier In an on-premises implementation, the regulated organisation may control the servers, database, update schedule and many administrative activities. In SaaS, some of these activities are performed by the supplier or its subcontractors. This changes the sources of evidence and the oversight mechanisms, but it does not transfer accountability for the regulated process. Responsibilities should be recorded in the contract, quality agreement or another controlled document. A standard subscription agreement will rarely address every issue relevant to GxP operation. Area Typical supplier responsibility Regulated company responsibility Expected evidence Product development Controlled development lifecycle, product testing and defect management Assess supplier processes and determine whether available evidence can be relied on Audit or qualification report, SDLC description, test summaries Infrastructure Hosting, platform maintenance, monitoring and technical backups Assess the service model, retention needs and recovery requirements Architecture, responsibility model, recovery test results Configuration Configuration functions and product documentation Approve the configuration required for the GxP process Configuration specification, review and tests Access Role, authentication and access-management capabilities Design roles, provision access and perform periodic reviews Role matrix, test evidence and review records Releases Release communication, product testing and deployment Impact assessment, regression decision and approval for use Release notes, impact assessment and regression tests Data Technical storage, export and protection mechanisms Classify data and control retention, completeness and use Data map, export tests and archiving procedures Incidents Detect and manage service-side events Assess GxP impact, take quality actions and make business decisions Tickets, root-cause analysis, CAPA and decision records The responsibility matrix should not leave gaps or create duplicated duties without a named owner. Particular attention is needed where the supplier assumes that the customer will test a control while the customer considers it part of the standard service. 5. SaaS validation in pharma step by step 5.1 Define the intended use The intended-use statement explains why the organisation is implementing the system, which processes it will support, who will use it and which decisions will rely on its data. It needs to be specific. Describing an application only as a quality management system does not show whether it manages documents, CAPA, training, audits, signatures or all of these functions. The boundary should identify interfaces, source systems, GxP records and functions that remain out of scope. A clear boundary reduces later disputes about testing and accountability. 5.2 Map the process and data lifecycle A process map shows where data are created, reviewed, approved, reported and archived. For SaaS, it should also cover transfers between services, APIs, reporting layers, backups, exports and supplier administration tools. The analysis needs to include metadata required to reconstruct an event. A PDF export may be insufficient when it omits change history, signatures, timestamps, relationships or record context. 5.3 Qualify the supplier and service Supplier qualification should be proportionate to system criticality and dependence on the external service. ISO 27001 certificates, SOC reports and security-test results may provide useful evidence. They do not automatically demonstrate that the customer’s GxP workflow and configuration are compliant. The assessment may cover: the supplier’s quality system and assignment of responsibilities; the software development lifecycle, testing, code review and defect handling; release, change and release-note management; security, vulnerability management and incident response; business continuity, backups and recovery testing; subcontractor oversight and data-processing locations; access to documentation, audit support and data on contract termination. Depending on risk, the organisation may use a questionnaire, document review, remote audit or on-site audit. One fixed method is unlikely to suit every supplier. 5.4 Agree requirements and acceptance criteria The user requirements specification should describe the required outcome and measurable acceptance criteria. Requirements need to be testable and traceable. In addition to business functions, the URS should address data integrity, security, audit trails, electronic signatures, retention, export, performance, availability and failure handling where relevant. A statement such as the system has an audit trail is too broad. The requirement should define which events are recorded, whether the record contains the user, date, time, old and new values and reason for change, and who can review and export the history. 5.5 Assess functional and data-integrity risks The risk assessment links requirements to potential failures and controls. For each critical function, the team should determine what can go wrong, the possible effect, how the failure may be detected and which control reduces the risk. Critical requirements need appropriately strong evidence from testing or another assessed source. Risk assessment should not be reduced to a mechanical multiplication of scores. Rationale, process knowledge and the quality of input information matter more than a superficially precise number. Risk needs to be reconsidered when the configuration, process, interface or supplier changes. 5.6 Design the configuration and controls Standard SaaS configuration can reduce the need for custom code, but configuration can still determine how a regulated process behaves. Statuses, approval paths, escalation rules, roles, dictionaries, forms and retention rules should be described, reviewed and controlled. Extensions, scripts, automation and integrations increase the customer’s responsibility. Their owners, repositories, deployment method and test process should be defined. Extensive customisation may also reduce the value of standard supplier evidence. 5.7 Validate migration and interfaces Data migration requires evidence of completeness, accuracy and preservation of record meaning. The strategy should define mapping rules, transformations, rejected records, record-count reconciliation and exception approval. Sampling may be suitable when its scope is justified by risk and data structure. Interfaces should be tested in both directions when two-way flow matters to the process. Tests should cover valid data, transmission failures, duplicates, message retries, time synchronisation and behaviour after a partial failure. 5.8 Test critical processes Testing should demonstrate that requirements are met and controls are effective. Supplier evidence may be leveraged when the organisation understands its scope, version, environment and approval method. There is no value in automatically repeating every product test. The customer must still verify its own configuration, data, interfaces, roles and critical workflows. The test package may include: positive tests of critical business flows; negative tests and exception handling; role and segregation-of-duty tests; audit-trail and electronic-signature verification; data migration and transfer-integrity tests; report, calculation and export tests; failure, recovery and business-continuity scenarios; acceptance tests performed by representative users. IQ, OQ and PQ terminology may be used where it forms part of the organisation’s quality system, but the labels should not replace a logical connection between requirements, risks and evidence. For a typical SaaS service, much of the installation or infrastructure evidence may come from the supplier. The configured use and intended purpose still require customer assessment. 5.9 Approve the validation and go-live decision The validation summary report should identify the system version and configuration, completed activities, test results, deviations, residual risks and release conditions. An open deviation does not always prevent go-live, but risk acceptance needs to be explicit, justified and approved by the appropriate roles. Before release, the organisation should confirm that procedures, support, training, access management, backup arrangements, monitoring and incident handling are ready. Technical validation without operational readiness does not provide sustained control. 6. Validation documentation for a SaaS system The documentation package should provide traceability from intended use and requirements to risks, controls, tests and the release decision. Document names differ between organisations. The important point is whether evidence is complete, approved, current and reproducible during an inspection. Document or record Main purpose SaaS-specific consideration GxP impact assessment Determine whether and to what extent the system is controlled Analyse functions and data flows rather than the product name alone Validation plan Define scope, roles, methods, environments and acceptance criteria Identify supplier evidence and customer activities Supplier assessment Justify reliance on the supplier and service Subcontractors, hosting, SDLC, releases and audit rights User requirements specification Record approved user and regulatory requirements Testable criteria for data, audit trails, signatures and export Risk assessment Link functions to risks and controls Configuration criticality, integrations and automated changes Configuration specification Provide a controlled record of system settings Workflows, roles, rules, extensions and retention settings Test protocols and evidence Demonstrate that requirements are met Version, environment, test data, results and deviations Traceability matrix Connect requirements, risks and tests Identify which evidence originated with the supplier Validation summary report Record the conclusion and release decision Residual risk, conditions and outstanding actions Validated-state plan Define post-release control Release assessment, regression testing, review and retirement Supplier documentation should be accepted deliberately. A supplier test report is useful only when its version, scope, environment, criteria and approval status are understood and relevant to the functions used by the customer. 7. Data integrity and ALCOA principles A SaaS system should support data that can be attributed to an individual, read, associated with the time of the activity, retained as original data or a verified copy and considered accurate. The extended ALCOA+ principles also address completeness, consistency, endurance and availability. The data-integrity assessment should cover: unique accounts and accountability for user actions; time synchronisation and the meaning of time zones; protection of original data and associated metadata; change control and audit-trail review capability; completeness of exports, reports and verified copies; data protection during integration and migration; retention, archiving, retrieval and readability for the required period; data recovery after failure and evidence that restoration works. It is not enough to confirm that an audit-trail feature exists. The organisation should determine whether it is always active for critical events, who can change its settings, how changes are displayed and how it will be reviewed. If supplier administrators have privileged access, their activities also require appropriate oversight. 8. SaaS releases and the validated state The main challenge may not be initial validation, but the pace of subsequent change. A supplier may issue many releases each year and activate some features automatically. The regulated company needs a process that quickly separates immaterial changes from changes affecting a GxP process. A release-management process should include: Obtain release notes and the planned deployment date. Identify affected functions, interfaces, data and requirements. Assess impact on configuration, risk and documentation. Decide the regression scope and required actions. Execute and approve tests before GxP use where this is possible. Update controlled documents, training materials and traceability. Approve the release or implement an agreed risk-control measure. The supplier agreement should provide enough notice, access to a test environment and clear information about release impact. Where updates cannot be deferred, the customer’s process needs a short assessment window, prioritised regression scenarios and a response plan for an unacceptable result. The validated state also depends on routine operational controls, including access reviews, incident management, CAPA, interface monitoring, periodic evaluation, training, audit-trail review, recovery testing and controlled system retirement. 9. Common SaaS validation mistakes 9.1 Relying only on supplier certificates An ISO 27001 certificate or SOC report may support assessment of security and organisational controls. It does not confirm that the customer’s configuration, workflow, report and user roles meet GxP requirements. 9.2 Reusing an on-premises CSV model without adaptation Repeating documentation and tests designed for locally installed software can create work without addressing the main SaaS risks. The strategy should leverage assessed supplier evidence and focus customer activity on configuration, data, integrations and use. 9.3 Leaving responsibility boundaries unclear An imprecise agreement makes it harder to obtain evidence, investigate incidents and assess releases. Responsibilities should also cover subcontractors, privileged support access, data copies and service termination. 9.4 Testing only the expected path A process may work correctly with ordinary data and fail when an integration breaks, a duplicate appears, an approval is withdrawn or a connection is lost. Negative tests and exception handling are important for critical workflows. 9.5 Treating validation as a one-off event Evidence quickly becomes outdated when subsequent releases are not assessed. The validated-state plan should be designed before go-live, rather than after the first major update. 9.6 Confusing availability with recoverability A high availability percentage does not prove that the company can recover complete records and resume a regulated process within the required time. Backup, retention, recovery objectives, data export and manual continuity procedures require separate assessment. 10. GxP SaaS validation checklist [ ] We have defined the intended use, system boundary and process owner. [ ] We have assessed the effect of each relevant function on patients, products and data integrity. [ ] We have identified the applicable GxP rules and electronic record types. [ ] We have documented data, metadata, interfaces, exports and archive flows. [ ] We have qualified the supplier and assessed its quality system and SDLC. [ ] We have reviewed infrastructure providers, subcontractors and data-processing locations. [ ] We have documented responsibilities in the contract and quality agreement. [ ] We have approved testable user requirements and acceptance criteria. [ ] We have completed a documented risk assessment of functions, data and interfaces. [ ] We have approved the configuration, roles, workflows, retention rules and extensions. [ ] We have verified data migration and interface completeness. [ ] We have tested critical workflows, exceptions, permissions, audit trails and signatures. [ ] We have linked requirements and risks to evidence in a traceability matrix. [ ] We have closed deviations or formally accepted the residual risk. [ ] We have approved the validation report and operational readiness before go-live. [ ] We have a process for release-note assessment, change control and regression testing. [ ] We perform periodic supplier, system, access and validated-state reviews. [ ] We have tested backup, recovery, business continuity and data export. [ ] We have defined archiving, retention and controlled service-exit arrangements. [ ] Personnel have been trained for their roles and responsibilities. 11. How to select a SaaS validation partner A validation partner needs to understand both quality requirements and the technical architecture of the service. Familiarity with CSV templates alone is insufficient for assessing integrations, identity design, cloud controls, automatic releases and supplier evidence. Before engagement, check whether the partner can: translate intended use into GxP scope and a risk-based strategy; assess a SaaS supplier, product documentation and shared responsibilities; prepare the URS, risk assessment, plan, tests, traceability matrix and report; connect quality requirements with security, architecture and data integration; design a sustainable process for maintaining the validated state; support QA, IT and business owners without replacing their regulatory decisions. The delivery model should reflect organisational maturity. One company may need an independent strategy review, another a complete documentation and testing workstream, and a third ongoing support for regular SaaS releases. 12. Why TTMS SaaS validation in pharma requires cooperation between quality assurance, process owners, IT, security and implementation teams. TTMS combines computer system validation capabilities with experience in software development, integration, testing and maintenance for regulated industries. Support can include GxP impact assessment, supplier qualification, validation strategy and documentation, architecture and configuration review, test preparation, data-migration assurance and maintenance of the validated state. The engagement can be adapted to a new implementation, a system already in operation or a programme covering several cloud applications. A practical TTMS engagement may include: Inventory of systems, functions and data flows within GxP scope. Gap assessment of evidence, controls and responsibility boundaries. A risk-prioritised implementation roadmap. Preparation and execution of the agreed validation activities. Support for releases, regression testing and periodic reviews. The objective is to produce evidence that reflects actual system use and can be maintained after go-live. Decisions on GxP scope, risk acceptance and system release remain part of the customer’s quality system. 13. Discussing SaaS validation with TTMS If your organisation is planning a cloud implementation or needs to bring an existing application under control, start with the intended use, supplier evidence and release lifecycle. This establishes the scope before detailed documentation and testing begin. Contact TTMS to discuss a validation strategy, SaaS supplier assessment or support for maintaining the validated state in a GxP environment. FAQ Does every SaaS system used by a pharmaceutical company require validation? No. The scope depends on the intended use of the system and its impact on GxP activities. Applications used solely for general administration may be outside the validation scope. However, systems that create, process, store, or manage critical GxP records require documented assessment and appropriate validation controls to ensure fitness for purpose. Can a SaaS product be certified as GxP compliant? No. There is no universal certification that automatically makes a SaaS product GxP compliant. While suppliers may offer features that support regulatory requirements and provide relevant documentation, compliance ultimately depends on how the regulated company configures, uses, and controls the system within its own processes and quality framework. Is the supplier’s ISO 27001 certificate sufficient? No. An ISO 27001 certificate demonstrates that the supplier has an established information security management system, but it does not verify the customer’s specific configuration, critical workflows, data integrity controls, or GxP compliance requirements. It should be treated as one component of supplier qualification rather than proof of validation. How should automatic SaaS updates be validated? Organizations should establish a process for reviewing release information, evaluating potential impact, classifying changes, and performing risk-based regression testing when required. Critical business processes and GxP workflows should be verified before use whenever possible, or within a controlled and justified post-deployment validation window. Does 21 CFR Part 11 apply to every SaaS system? No. The applicability of 21 CFR Part 11 depends on whether the system creates, maintains, modifies, archives, retrieves, or transmits electronic records required by FDA regulations and whether electronic signatures are used. Each application should be assessed against its intended use and the relevant predicate rules to determine Part 11 requirements.
Read
RAG for Chatbots using CrewAI: Notes from a TTMS Tech Talk
Tech Talk is an internal series of technology sessions for TTMS employees, where we share knowledge and project experience. We demonstrate tried-and-tested tools, discuss challenges we have encountered and explain the solutions that have helped us in our work. Topics include artificial intelligence, data analytics, Salesforce, AEM and project management. Presentations are followed by time for questions, discussion and sharing ideas. During the session “RAG for Chatbots Using CrewAI”, held on 17 September, Jakub Kraśniewski, Senior AI Developer at TTMS, discussed improvements to a chatbot using a client’s documentation. He presented the challenges involved in preparing and retrieving information, the solution implemented and the approach to evaluating answer quality. The project involved a company in the education sector whose customers were preparing for a certification exam. The chatbot was intended to help them find information about registration, exam procedures, grading and appeals, thereby reducing the support team’s workload. It used several hundred pages of publicly available PDF documents, mainly in English. The team needed a way to retrieve relevant information from these materials while meeting a response time requirement of around 4 to 5 seconds. 1. How does RAG help a chatbot use company knowledge? Jakub began the presentation by explaining how RAG (Retrieval-Augmented Generation), a method of generating answers using retrieved source material, works. The system finds information relevant to the user’s question and passes it to a language model as context for the answer. In this project, the retrieved material consisted of passages from documentation describing exam rules and procedures. After extracting text from the documents, the system divides it into smaller chunks. An embedding model (an AI model that represents semantic features of text as numbers) converts these chunks into vectors stored in a database. The user’s question is processed in the same way. Comparing these representations allows the system to retrieve passages that are semantically related to the question. Jakub emphasised that the team is responsible for the quality of the material passed to the model. This involves checking whether the text was extracted correctly, whether the chunking preserved the necessary context and whether retrieval provides information useful for answering the question. The challenges the team encountered in the CrewAI-based solution demonstrated the importance of these steps. 2. What made information retrieval difficult in the CrewAI project? After explaining the basics of RAG, Jakub shared his experience from a project using CrewAI, a framework for building AI agent-based systems. He discussed three problems encountered in the configuration used: overly large text chunks, the absence of an additional relevance assessment and errors in PDF text extraction. 2.1 Overly large document chunks In the configuration Jakub described, text was split into chunks of 4,000 characters. The system retrieved five such chunks for each question, passing up to approximately 20,000 characters of source material to the model. A large chunk can contain information on several different topics, making it harder to match it to a specific question. The model generating the answer must then select the relevant information from the supplied content. In this project, the chunking approach therefore needed to be adapted to the structure of the documents and users’ questions. 2.2 No additional assessment of search result relevance Jakub pointed out that the configuration lacked reranking, which involves reassessing and reordering search results according to their usefulness for answering the user’s question. The system can first retrieve a larger number of passages, then assess them further to select those most useful for preparing an answer. Jakub presented this method as a potential improvement whose value should be evaluated by checking both answer quality and response time. 2.3 Incorrect text reading order in multi-column PDFs Another problem involved document text extraction. The tool read multi-column PDFs row by row, merging content from adjacent columns. This disrupted the order of sentences and made subsequent information retrieval more difficult. The resulting text was then split into chunks. The error therefore originated during data preparation and affected the subsequent stages of document processing. This example showed why evaluating RAG quality should begin with comparing the extracted text against the source document. 3. How does response time affect the choice between Classic RAG, Agentic RAG and Graph RAG? A key project requirement was a response time of around 4 to 5 seconds. Jakub discussed three RAG approaches in terms of data preparation costs, the ability to evaluate their operation and the time needed to handle a question. Approach How it works, as discussed during the session What to consider when choosing Classic RAG Retrieves passages from a knowledge base, optionally reranks them and passes the context to the model. Document chunking quality, retrieval relevance and the amount of context provided. Agentic RAG An agent selects tools and a retrieval method, running additional queries as needed. The ability to adapt retrieval to the question, along with the time and cost of additional operations. Graph RAG Retrieval uses a knowledge graph describing entities found in the source material and the relationships between them. The effort required to build and maintain the graph, and how useful the relationships are for answering users’ questions. In an agentic approach, the model can use several tools, such as vector search, keyword search or filtering by metadata describing the document. Additional steps allow the system to expand its search for information, while their number and sequence affect response time. In the graph-based approach presented, some of the work takes place when building the knowledge base. Entities and the relationships between them are extracted from the text. This mechanism also underpins GraphRAG as described by Microsoft. Jakub highlighted the costs of this preparation and the difficulty of manually analysing a complex graph. In this project, the response time requirement favoured further development of classic RAG. The team focused on document chunking and context selection. 4. How does hierarchical document chunking help preserve context? The solution organised the material into three connected levels: pages, paragraphs and sentences. The system retained information about which paragraph each sentence belonged to and which page contained that paragraph. Content was represented in the vector database at different levels of detail. This allowed retrieval to identify both individual sentences and larger passages containing the required information. According to Jakub, the additional cost of storing and processing these representations was acceptable given the volume of material in the project. Finding a relevant sentence made it possible to retrieve its entire paragraph and provide the model with broader context. The system could also retrieve the whole page when needed. Suppose a user asks about the deadline for appealing an exam result. The system finds a sentence specifying the deadline, then retrieves the entire paragraph explaining when the appeal period begins and how to submit an appeal. This allows the model to account for these conditions in its answer. 5. How can you evaluate RAG quality using your own data? In the final part of the presentation, Jakub emphasised the importance of a benchmark, a set of tests used to compare different versions of a solution. He discussed checking retrieval results against information labelled by a human and using a language model to evaluate answers. In practice, it is useful to assess two stages separately. The first concerns retrieval: did the system return a passage containing the required information? The second concerns the answer: did the model use the supplied material correctly? This distinction helps identify which stage needs improvement. In additional information shared after the session, Jakub clarified the testing method and results. The test set included questions covering the full scope of the documentation, along with real user questions collected anonymously during a prototype launch at the beginning of the year. Answer accuracy increased from around 70% to around 98%, an improvement of approximately 28 percentage points. This result applies to the internal test conducted in this project. According to Jakub, the solution also maintained a fast response time. When he shared these details, the chatbot had completed internal testing, and the company planned to make it available to a subset of customers. Reducing the support team’s workload and making information easier to access remained deployment goals. Assessing whether those goals have been achieved requires data from actual use. The embedding model is another component to evaluate. Jakub noted that its selection should take into account the language of the source material and its performance on the team’s own dataset. The choice of this model affects which passages the system retrieves before it begins generating an answer. 6. What can companies implementing a chatbot learn from this experience? The project shows how specific requirements guide RAG development. The expected response time helped narrow down the choice of solution, document analysis revealed problems with text extraction and chunking, and an internal test made it possible to assess the impact of the changes. When planning a similar implementation, it is worth addressing five areas: Source material: check whether document text extraction preserves meaning and reading order. Document chunking: adapt chunk size and the connections between chunks to the structure of the material. User questions: prepare a test set that reflects the tasks the chatbot is intended to support. Response time: establish expectations and account for them when comparing approaches. Quality assessment: check both the relevance of the retrieved information and how it is used in the answer. Let’s talk about AI in your company TTMS is home to experts who, like Jakub, combine technical knowledge with experience from client projects. During Tech Talks, they share solutions tested in practice and apply what they have learned to subsequent implementations. Are you planning a chatbot that uses your company’s documentation, or looking to improve the answer quality of an existing tool? Let’s talk. We will review your materials, users’ needs and business goals to recommend an appropriate way to use AI. Contact the TTMS team! What documents can a RAG chatbot use as a knowledge base? A RAG chatbot can use company policies, product manuals, procedures, FAQs and other materials containing information relevant to its users. Sources may include PDFs, Word documents, website content and knowledge base articles, depending on the integrations available. Scanned documents require optical character recognition (OCR) to turn images of text into searchable content. Tables, diagrams and complex layouts may need additional processing to preserve their meaning. Before adding documents, check that they are accurate, current and approved for the intended audience. Clearly structured materials help the system retrieve information and provide useful context for its answers. How do you keep a RAG chatbot’s knowledge base up to date? Keeping a RAG chatbot up to date requires a process for detecting and processing changes in its source materials. Depending on business needs, updates can run on a schedule or be triggered when a document is added, edited or removed. The system then updates the searchable content and its associated representations, such as embeddings. Version information and effective dates help distinguish current guidance from older material. Deleted or superseded documents should also be removed from active search results, and cached answers may need refreshing. Assigning an owner to each content area helps ensure that someone remains responsible for the information the chatbot uses. Can a RAG chatbot provide sources for its answers? Yes, a RAG chatbot can include links, document titles, page numbers or quoted passages alongside its answers. This requires the system to preserve source information when processing documents and connect retrieved passages to the response. Useful citations let users open the relevant material and check the context for themselves. The system should also verify that each citation supports the claim it accompanies. A source link alone provides no guarantee that an answer accurately reflects the document. During testing, teams should check both answer quality and citation accuracy, including whether users can access the referenced material. How can a RAG chatbot respect access permissions for company documents? A RAG chatbot can use the signed-in user’s identity and access rights to determine which documents it may retrieve. Permission checks should happen before restricted content reaches the language model. The same controls need to cover document previews, citations and any cached responses that contain protected information. When access rights change in a source system, those changes must also be reflected in the chatbot’s retrieval process. Teams should test the solution using accounts with different roles, including users with limited access. These checks help confirm that each person receives answers based on information they are authorised to view. What should a RAG chatbot do when it cannot find an answer? When the available documents provide insufficient information, a RAG chatbot should clearly explain that it cannot answer reliably from its sources. It can ask a clarifying question if the request is ambiguous or suggest a related document that may help. For questions requiring further assistance, it can direct the user to the appropriate team or support channel. The system needs explicit rules for handling incomplete, conflicting or missing information. Testing should include questions whose answers are absent from the knowledge base, so the team can assess this behaviour. Reviewing unanswered questions can also reveal gaps in company documentation and priorities for future updates.
Read
You’ve Deployed Moodle. How Do You Import Your First Training Materials?
Having Moodle installed and configured is only half the journey toward launching training in your company. The next step is to bring real content into it: courses from a previous system, ready-made SCORM packages, or a list of employees who need access to the platform. In this article, we walk through this process step by step — and what to do if you don’t have any training materials yet at all. 1. Before You Start: Identify Your Starting Point for Importing into Moodle The import method depends on exactly what you want to bring into Moodle. In practice, companies find themselves in one of three situations: You already have a ready-made course in SCORM format – produced earlier, purchased from an external provider, or exported from another LMS. In this case, you simply need to import it as an activity within a course. You have a full backup of a course from another Moodle instance (an .mbz file) – e.g., from a test environment, a previous deployment, or from a company that previously managed your platform. In this case, you import the entire course along with its structure. You don’t have either of the above yet – instead, you have presentations, PDF procedures, onboarding recordings, or simply knowledge in your employees’ heads that still needs to be turned into a course. This is the most common situation right after deployment and requires a different approach, which we cover in the final section. The instructions below apply to the first two cases. Option names and their locations may vary slightly depending on the Moodle version, but the main stages of the process remain similar. For certainty, it’s also worth checking the current official Moodle documentation. You’ll find links to the relevant materials further in the article. 2. Importing an Entire Course from a Backup File (.mbz) If you have an .mbz file – a full course backup including section structure, activities, and (optionally) files – the process looks as follows: Log in to Moodle with teacher or manager permissions and go to the course you want to upload content into (this can be a newly created, empty course). From the course menu, select More → Course reuse → Restore. Select the .mbz file – you can upload it from your computer or point to a file already located in the course’s file area. Moodle will guide you through several screens: file confirmation, restore settings (whether to merge the content with the existing course or overwrite it entirely), and selection of which elements should be restored. At the review stage, you’ll see a full list of what will be imported. This is your last chance to go back and make corrections. Once confirmed, the restore process runs in the background – depending on the size of the course, this can take anywhere from a few dozen seconds to several minutes. Important note: a full backup usually does not include user data such as quiz results or forum posts, unless this option was deliberately selected when creating the backup. This is a safeguard that protects against accidentally transferring personal data between environments. You can find more information about creating backups and restoring courses in the official Moodle documentation. A detailed description of the process is available in the materials. 3. Importing Individual Elements from Another Course If you don’t need an entire course, but only selected materials – e.g., a single module, a quiz, or a set of files – Moodle offers a separate Import feature, available in the same place as Restore: Go to the destination course and select More → Course reuse → Import. Search for the source course (you must have editing permissions in it). Select which types of elements you want to transfer: activities, blocks, filters. On the next screen, select the specific items – you can choose a single quiz or file instead of an entire section. Confirm the import and wait for the completion message. This method is convenient when you’re building several similar courses (e.g., for different departments) and want to reuse some shared materials instead of creating them from scratch each time. 4. Importing a SCORM Package as a Course Activity A SCORM package is the most popular format for a ready-made e-learning course – regardless of whether it was created by an external provider, an authoring tool, or exported from another system. The import looks different than for a course backup, because SCORM here is a single activity within a course, not an entire course: Go to the course where the training should appear and turn on editing mode. In the chosen section, click Add an activity or resource and select SCORM package from the list. Upload the .zip file containing the SCORM package. Configure the basic settings: grading method (e.g., based on the highest score or the most recent attempt), the number of allowed attempts, and how the content is displayed (in a new window or within the course page). Save and return to the course – you’ll see the new activity, ready to be opened by users. It’s worth testing the package from a test account before making it available to the target group – especially if the SCORM package comes from an external source and you’re not sure about its compatibility with your Moodle version. 5. Importing a User List and Assigning Roles Materials are only one side of the equation – the other is the people who will use them. Instead of adding each employee manually, you can import a list in bulk: Prepare a CSV file with columns such as first name, last name, email address, and username (the exact required format depends on the platform’s configuration). Go to Site administration → Users → Upload users. Upload the CSV file and review the preview – Moodle will show how it interprets each column and whether there are any data errors. Confirm the import. New accounts will be created automatically, and if the file included the appropriate columns, users can be immediately enrolled in the specified courses. Separately assign roles (e.g., teacher, participant, manager) at the course or category level, if the import didn’t already do so. If the company uses SSO login (e.g., via Azure AD or Microsoft 365), part of this process can be automated through account synchronization – however, that’s a separate topic beyond manual import. You can find more information about the features described above in the official Moodle documentation: Import course data describes moving selected activities and resources between courses, SCORM settings explains adding and configuring SCORM packages, and Upload users describes bulk account creation and course enrollment using a CSV file. Information on Microsoft 365 integration and user synchronization is also described in Microsoft 365 integration. 6. What to Do When You Don’t Have Any Materials to Import Yet This is the most common scenario right after deployment: the platform works correctly from a technical standpoint, but there’s nothing to upload to it yet. The company has knowledge – procedures, presentations, recordings – but not in a format that Moodle recognizes as a ready-made course. In this situation, there are two paths: Prepare the content yourself, with the help of the AI4E-learning tool. The team defines the training goal and provides the source materials they have (documents, presentations, recordings), and the tool generates a course structure from them, complete with audio narration and quizzes, exporting a ready SCORM package – in exactly the format that can be imported using the method described above. Commission course production to the TTMS team. If you need full graphic design, animation, or language versions, custom production covers the entire process: from the script, through graphics and interactions, to export and testing on the platform. Both paths lead to the same end result: a package ready to be uploaded to the platform you already have configured. 7. Summary Launching Moodle is an important step, but that’s when the practical part of the whole process really begins: transferring existing courses, organizing users, and populating the platform with content that employees will actually use. The starting point can be different for every organization. Sometimes it’s ready-made SCORM packages and courses from a previous LMS, and sometimes it’s presentations, documents, procedures, and expert knowledge that still needs to be turned into training. That’s why it’s worth looking at Moodle as part of a larger learning ecosystem within the organization. TTMS can support the entire process: from needs analysis, Moodle deployment and configuration, through migration and integrations, to preparing and launching training content. If source materials already exist, AI4E-learning can additionally help turn them into ready-made courses and significantly shorten the path from company knowledge to training available to employees. If you’re currently wondering how to move from a deployed platform to a fully functioning training environment, let’s talk about your starting point. We’ll help you determine the right scope of implementation and the next steps tailored to your organization’s materials, systems, and needs. FAQ Does importing a course into Moodle also transfer user results and history? It depends on how the course is transferred. Importing content from another Moodle course does not include user data, such as forum posts. When restoring a course from a backup, the scope of transferred information depends on the backup’s content and the available permissions. What’s the maximum size of a SCORM file that can be uploaded to Moodle? This depends on the settings of the specific installation – the upload file size limit configured on the server and within Moodle itself. If needed, this limit can be raised at the platform configuration level. Can I import a course from a completely different LMS, not just from Moodle? It depends on the format in which the source system exports data. If it provides a SCORM package, it can be imported as an activity in a Moodle course. Fully transferring the course structure, roles, and data from another LMS is usually a separate migration project that requires the scope to be determined in advance. What should I do if the import fails with an error? There can be many causes, ranging from file size limits and environment configuration to compatibility issues when restoring course backups. In such a case, it’s worth analyzing the specific error message along with the Moodle environment’s configuration. Can an imported SCORM package be edited later directly in Moodle? No – a SCORM package is a closed content package, and Moodle treats it as a ready-made file to be played back, not editable material. To make changes, you need to modify the course in the tool where it was created (e.g., in AI4E-learning or another authoring tool), export it again, and replace the previous version of the activity in Moodle.
Read
ChatGPT for financial services: what does combining GPT with professional data sources offer?
On 10 September 2026, OpenAI announced ChatGPT for Financial Services, a solution combining GPT-6 Astra with professional financial data sources and tools for preparing analyses. The product was developed in collaboration with Morgan Stanley and Evercore. It is designed for financial institutions, with an initial focus on investment banking and equity research. It allows analyst teams to find data, perform calculations and prepare client materials in one place. This could reduce the time spent gathering information and transferring it between tools. In this article, you will learn: what data and features ChatGPT for Financial Services offers, what preparing a company analysis with GPT could look like, why metric calculations and data sources need to be checked, which stages require an analyst’s review, how to assess whether implementation is worthwhile for your company. How does ChatGPT for Financial Services support analysts? Materials published by OpenAI and its data providers describe several specific use cases: Comparing companies. Daloopa, a provider of company financial data, makes selected data and metrics available for comparing business performance. Source references help analysts verify where the figures come from. Finding companies that meet specific criteria. Daloopa also describes searching for companies by business activity or geographical region. The resulting list can provide a starting point for further market analysis. Preparing client materials. OpenAI describes creating valuation models, research notes and presentations using company templates for Excel, Word and PowerPoint. ChatGPT for Financial Services provides access to selected data from Daloopa, PitchBook, LSEG News and Crunchbase. OpenAI is also developing integrations that will allow institutions to use data covered by their existing subscriptions. These include S&P Capital IQ, LSEG, MSCI, Dow Jones Factiva and Moody’s. From data to company analysis: five steps in the workflow Let’s walk through preparing a comparison of two industrial companies ahead of a client meeting. The analyst needs to assess profitability, explain material differences and prepare a short note with a results table. Using fictional data, we will show what to check during a pilot, from selecting information to approving the final material. 1. Defining the question and scope of the comparison First, we establish which period to compare: the last full year, a six-month period or the trailing twelve months. We also check whether the figures cover the entire corporate group or an individual company, which currency they use and how each metric was calculated. In our example, we use consolidated data for both groups for the same calendar year. Amounts are stated in millions of euros. Before comparing results, we need to check the start and end dates of the reporting periods. One company’s financial year may end in December, while another’s ends in March. The documentation for the US SEC’s EDGAR database also highlights these differences. The analyst must then decide how to account for the mismatch and whether additional data is needed. The agreed approach should be recorded in the instructions for the AI and included with the completed analysis. This gives the model clear guidance and helps the reviewer understand which data was compared and why. 2. Gathering data and identifying its sources For each important figure, record the company and period it relates to, the units used and how it was calculated. A reference to the specific table or explanatory note in the report is also needed. Keeping the source document and its retrieval date makes it easier to review or update the analysis later. According to OpenAI’s description, ChatGPT for Financial Services lets users locate specific tables and document passages, highlighting the information used in the analysis. In our example, we compare EBITDA, or earnings before interest, taxes, depreciation and amortisation. The reviewer should be able to trace a reported value back to the company’s report and check how it was calculated. This also allows them to confirm that the figure covers the correct period and scope of operations. 3. Aligning definitions before comparing margins Companies may report adjusted EBITDA that excludes selected costs. These adjustments increase the value of the metric. Before comparing profitability, it is therefore necessary to check which adjustments have been applied. The US SEC also highlights differences in how individual companies calculate financial measures. Let’s look at two fictional companies. We assume that both calculate EBITDA before adjustments using the same principles. Company A then adds back EUR 4.59 million in costs that it excludes when calculating adjusted EBITDA. As a result, the metric rises from EUR 27.57 million to EUR 32.16 million. Company B has no such costs, so its figure remains unchanged. Illustrative example. Consolidated data for the same calendar year. Amounts are stated in EUR million. Item Company A Company B Revenue 229.73 183.78 EBITDA before adjustment 27.57 23.89 Costs excluded when calculating adjusted EBITDA 4.59 0.00 Adjusted EBITDA 32.16 23.89 EBITDA margin before adjustment 12% 13% Adjusted EBITDA margin 14% 13% After the adjustment, Company A’s margin is 14%, exceeding Company B’s margin of 13%. Before the adjustment, Company B has the higher margin: 13% compared with 12%. In this example, the treatment of costs determines which company has the higher EBITDA margin. The analyst should therefore check which costs make up the EUR 4.59 million adjustment and whether they also occurred in previous years. This helps them assess whether excluding these costs is justified for the analysis being prepared. They can also present both scenarios and explain the difference to the client. AI can help gather data and recalculate margins, while the expert assesses whether the adjustment is justified and how it affects the conclusions. 4. Verifying calculations in the spreadsheet In our example, simply divide EBITDA by revenue: 27.57 ÷ 229.73 gives a margin of approximately 12%, while 32.16 ÷ 229.73 gives approximately 14%. The displayed amounts are rounded; the spreadsheet should retain full precision for its calculations. More complex analyses may require currency conversion, alignment of reporting periods or the preparation of several forecast scenarios. The reviewer should be able to trace each of these steps. It is therefore worth asking AI to create a spreadsheet in which source data, assumptions and formulas are clearly separated. The analyst can then check the calculations and see how changing a single value affects the result. To test the spreadsheet, you can halve the adjustment, reducing it from approximately EUR 4.59 million to EUR 2.30 million. Company A’s adjusted EBITDA should then be approximately EUR 29.86 million, with a corresponding margin of 13%. These amounts are rounded for presentation; the spreadsheet should calculate the change using unrounded values. After making this change, check the comparison table and the commentary on the results as well. Both companies would now have the same margin, so the conclusion that Company A has a higher margin would need updating. This is a simple way to assess whether the calculations and accompanying text remain consistent. 5. Preparing client materials and reviewing conclusions The completed analysis can be presented in the company’s preferred format. According to OpenAI’s description, an administrator can share Excel, Word and PowerPoint templates with the team for the tool to use when creating documents and presentations. In our example, the client should receive a results table and a short explanation of how the cost adjustment affects the margin comparison. The expert reviewing the material checks whether the conclusions match the calculations and answer the client’s question. If anything needs clarification, they can request a further explanation or another version of the analysis. Time measurements should also include reviewing the material and making corrections before approval. How can you protect data and preserve a record of the analysis? When preparing a client analysis, the team may use public reports, paid databases and confidential documents. It is necessary to establish who can access this information, where it will be stored and who can receive the finished material. According to the ChatGPT Work security documentation, business data is encrypted and is not used to train models by default. Data retention periods, processing locations and the scope of recorded activity depend on the settings and connected services. Before implementation, check which user and tool actions are logged and which records can be exported. During the pilot, keep the source documents, successive versions of the spreadsheet and the final material, together with a record of who approved it and when. Then check whether this documentation allows you to reproduce the calculations and trace the approval of the analysis. Separately, verify whether system logs allow user and tool activity to be traced to the extent required by the company. How can you assess whether implementation is worthwhile? Start by choosing a task the team performs regularly, such as updating a company comparison after quarterly results are published. Before testing, measure how long this analysis takes using the existing method and define its quality requirements. These findings will provide a baseline for comparison with AI-assisted work. The time needed to review and correct the analysis must be added to the preparation time. OpenAI highlights this in its guidance on assessing the business value of AI, also recommending that implementation and ongoing usage costs be included. In practice, it is worth comparing: Metric What does it tell us? Time from starting the task to approving the analysis Does the client receive the finished material sooner? Include waiting time between stages. Total time spent by the analyst and reviewer Does the team spend fewer hours on preparation, review and corrections? Number of errors affecting the results or conclusions Does the analysis meet the same quality requirements as the existing approach? Accuracy and completeness of source references Can the origins of key figures and information be verified? Time needed to update the analysis How efficiently can new data be incorporated and the calculations and conclusions that depend on it be updated? Cost per approved analysis What is the cost of the finished material, including team time, the tool, data and the share of implementation and maintenance costs allocated to that analysis? The test should cover several tasks of varying difficulty. Define the assessment criteria before it begins. Someone performing the same analysis for a second time already knows the data and some of the answers, which may shorten the time needed. It is therefore worth using comparable tasks and varying the order in which participants work with AI and with the existing method. If AI saves time, check how the team used it. They may have prepared more analyses, responded to clients sooner or reduced overtime. The implementation assessment should show separately how the time saved was used and whether company spending decreased, and by how much. When is it worth starting a pilot? Consider a pilot if the team regularly gathers data from multiple sources and updates similar analyses. Choose a task that takes analysts a significant amount of time, such as comparing data from company reports. Assign a person to lead the pilot and experts to review the results. If the team only occasionally analyses a few annual reports, check whether tools already approved for use within the company are sufficient. Where data retrieval and calculations are already automated, identify a specific task that the new tool could improve. OpenAI makes the product available to financial institutions that meet its access requirements and directs interested companies to its sales team. Pricing, detailed terms and availability for a particular institution in Poland must be confirmed with the provider. Availability information. The implementation decision should be based on the pilot results: the quality of the analyses, the time needed to prepare and review them, and the total cost of the work. The test will also show whether the tool provides access to the data the team needs. Want to explore where AI could improve analysts’ work in your organisation? Talk to the TTMS team about choosing a task for a pilot, connecting the necessary data sources and assessing the results. How does ChatGPT for Financial Services differ from analysing reports in ChatGPT? ChatGPT for Financial Services provides access to selected professional financial data directly within the tool. It also supports references to specific tables and document passages, as well as the preparation of materials using company templates. When assessing its suitability for a team, check whether the available sources cover the companies, periods and metrics the team needs. Does ChatGPT for Financial Services require separate financial data subscriptions? Selected datasets are included in the product. These cover some of the information supplied by the providers named by OpenAI. The company is also developing integrations intended to let institutions use data covered by their existing subscriptions. Before purchasing, confirm which data is included in the offering and which requires additional access rights. Can ChatGPT for Financial Services be used to analyse companies listed on the Warsaw Stock Exchange? This depends on the availability of data for individual companies. Check whether the tool provides their financial statements, relevant metrics and historical data. The launch announcement alone does not confirm full coverage of the Warsaw Stock Exchange. The best way to assess the product’s suitability is to test it on several companies the team regularly analyses. What should you do if data from ChatGPT differs from the figures in a company’s report? Start by comparing the sources, reporting periods, units and definitions of the metrics. A discrepancy may arise, for example, from using standalone rather than consolidated financial data, or from including EBITDA adjustments. Also check whether the company has published an updated report. The analyst should explain the discrepancy and document which value they used and why.
Read
Automation Best Practices in Software Testing for 2026
Software release cycles keep shrinking, and testing teams are expected to keep pace without sacrificing reliability. Automation has become a core part of modern software delivery, but writing more scripts does not automatically lead to faster feedback, stronger coverage, or more dependable releases. Teams getting real value from automation treat it as an engineering discipline integrated with the wider QA and software delivery process. This article covers the practices that make automation sustainable in 2026, including test prioritization, methodology and tool selection, maintainable script design, CI/CD integration, continuous maintenance, and code ownership. 1. Why Test Automation Best Practices Matter More in 2026 Applications increasingly depend on connected services, frequently changing interfaces, and shorter delivery cycles. Automated testing may cover web applications, mobile products, APIs, integrations, and business-critical user journeys, making the way automation is planned, implemented, and maintained as important as the number of tests in the suite. Without clear standards, automation can become another source of delivery friction. Unstable tests slow down CI/CD pipelines, outdated scripts lose alignment with changing requirements, and duplicated coverage increases execution and maintenance effort without producing better evidence. As discussed in our guide to AI end-to-end testing, sustainable automation requires clear ownership, traceability, regular maintenance, and a deliberate connection between requirements, test intent, execution, and results. 2. A Decision Framework for What to Automate in Software Testing Not every test belongs in an automated suite. Teams need a repeatable way to identify scenarios where automation will provide lasting value rather than create additional maintenance work. 2.1 Scoring Test Cases by Frequency, Stability, and Cost A practical scoring model evaluates each candidate across several dimensions: how often the test runs, how stable the underlying feature is, how important the workflow is to the business, and how much effort the test will require to automate and maintain. Strong candidates are usually repeatable scenarios with clear expected results, stable preconditions, reliable test data, and a meaningful impact on release confidence. A frequently executed test may be valuable, but frequency alone is not enough. Teams should also consider whether the scenario can be executed consistently and whether its expected outcome can be verified without subjective interpretation. 2.2 Keep Judgment-Based Testing Manual Exploratory testing, first-impression usability reviews, visual assessments, and scenarios that depend heavily on human interpretation are usually better handled manually. Automating these activities can remove the flexibility and observation that make them valuable. Rarity alone should not exclude a test from automation. An unusual scenario may still deserve automated coverage when a failure could interrupt a critical process, compromise data, or create significant operational risk. The decision should reflect business impact as well as execution frequency. 2.3 Prioritize Business-Critical User Paths After unsuitable candidates have been removed, rank the remaining tests by business impact and regression risk. Authentication, checkout, account access, approvals, and core transaction flows are common priorities because failures can prevent users from completing essential tasks. Starting with these workflows allows the automation suite to protect the parts of the application that matter most. Lower-impact scenarios can be added later when their expected value justifies the development and maintenance effort. 3. Match the Automation Approach to the Application and Team Once teams have identified the right candidates for automation, they need to choose an approach that fits the application, delivery model, and available skills. The decision should balance execution speed, maintainability, technical control, accessibility for QA, and the effort required to integrate automation with the existing development workflow. 3.1 Use the Test Pyramid to Balance Feedback and Coverage The test automation pyramid remains a useful starting point. Fast unit tests usually form the broadest layer, integration and service-level tests verify interactions between components, and a smaller set of end-to-end tests validates complete user journeys. The exact proportions should reflect the application architecture and its risks. A system built around multiple services may need stronger integration coverage, while a business application may require more end-to-end validation of critical workflows. The goal is to detect problems at the lowest practical level while retaining enough end-to-end coverage to confirm that essential user journeys work as expected. 3.2 Choose Between Code-Based, Codeless, and Hybrid Automation Code-based automation provides direct control over test architecture, integrations, reusable components, and repository conventions. It is often appropriate when a team has strong engineering skills, complex testing requirements, or an established automation framework. Codeless and low-code approaches reduce the amount of scripting required to define common test scenarios. They can make automation more accessible to manual testers and domain specialists, although teams should still evaluate how the platform handles complex logic, maintenance, version control, and code ownership. A hybrid approach combines accessible test definition with standard code-based automation. QA professionals can define and review test intent, while automation engineers maintain technical standards and review the resulting code. This model can reduce handovers without limiting the team to a proprietary execution format. 3.3 Evaluate Technical Fit and Long-Term Ownership The right methodology depends on what the team is testing and who will maintain the automation. Complex backend behavior and service integrations may require direct technical control, while repeatable web user journeys may be suitable for higher-level automation. Teams should also consider where generated automation will run, whether the output can be reviewed in the existing repository, how results return to the QA workflow, and whether the chosen approach supports the organization’s deployment and security requirements. Tool popularity matters less than alignment with the team’s application, skills, governance model, and long-term maintenance responsibilities. 4. Design Test Automation for Maintainability Script and framework design have a major influence on long-term reliability, regardless of the selected tool. Maintainable automation separates reusable technical components from test intent, follows consistent repository conventions, and makes failures easier to understand and repair. 4.1 Using Stable Locators and Resilient Element Selection Locators based on visual position, generated identifiers, or deeply nested DOM paths can break when the interface changes. Where possible, teams should use selectors based on stable and meaningful attributes, such as dedicated test identifiers, accessible roles, labels, or other elements that reflect how users interact with the application. A locator should be both stable and specific enough to identify the intended element. The goal is not to eliminate maintenance entirely, but to reduce unnecessary failures caused by implementation details that are unrelated to the behavior being tested. 4.2 Apply Reusable Design Patterns Patterns such as the Page Object Model can separate interactions with the application from the business logic being verified. When an interface element changes, the team can update the relevant reusable component instead of modifying every test that uses it. The appropriate structure may also include component objects, shared fixtures, helper functions, reusable actions, and project-specific abstractions. Teams should select patterns that match the application architecture and apply them consistently across the repository. 4.3 Define Clear Assertions Every automated scenario should include an explicit and observable expected result. A test that performs a sequence of actions without verifying the outcome may pass even when the underlying business process is not working correctly. Assertions should confirm the intended behavior rather than incidental implementation details. Clear expected results also make test cases easier to review, automate, diagnose, and trace back to the original requirement. 4.4 Manage Test Data as a Dedicated Discipline Test data should have clear ownership and a repeatable setup process. Data creation, seeding, reuse, protection, and cleanup should be considered when the test is designed rather than added after the script has already been implemented. Teams should also avoid hidden dependencies on data left behind by earlier executions. Predictable test data makes failures easier to reproduce and reduces false results caused by stale, incomplete, or conflicting records. 4.5 Keep Tests Independent and Isolated Automated tests should not depend on the order in which other tests are executed. Each test should begin from a known state and establish the preconditions required for its own scenario. Isolation can be implemented through fixtures, controlled data setup, separate browser contexts, API-based preparation, environment resets, or cleanup procedures. When one test fails, that failure should not create misleading results elsewhere in the suite. 4.6 Follow Repository Conventions Automation code should follow the same structural and quality standards as the rest of the project. Consistent naming, fixtures, helpers, hooks, error handling, formatting, and review rules make generated and manually written tests easier to understand and maintain. Repository alignment becomes particularly important when automation code is generated rather than hand-written. Generated automation should fit the existing framework rather than introduce a parallel structure that the engineering team must maintain separately. 5. Integrate the Right Tests at the Right CI/CD Stage Automated tests provide the greatest operational value when they are integrated with the delivery pipeline and return timely, actionable results to the people responsible for the change. The goal is not to run every test after every update, but to apply the right level of validation at each stage. 5.1 Match Test Scope to the Pipeline Stage A staged pipeline balances feedback speed with test depth. Fast unit tests and static checks can validate individual changes early, while integration tests and a relevant regression subset can provide broader evidence during pull or merge request review. More extensive regression testing can run after changes are merged, before deployment, on a schedule, or when the risk of a release justifies wider coverage. Smoke tests serve a different purpose. They verify that a deployed application is available and that its most critical user paths remain operational. They should complement, rather than replace, deeper regression testing. The exact structure and runtime expectations should reflect the application architecture, infrastructure, release cadence, and business risk. Teams should define their own quality gates based on the type of change and the evidence required before it can move forward. 5.2 Select Tests Based on Change and Risk Running the full suite for every code change can create unnecessary delays as automation grows. A more sustainable approach selects tests based on the components affected by the change, related requirements, business-critical workflows, previous execution results, and known areas of risk. Test selection should remain transparent. Teams need to understand why a test was included or excluded and should be able to expand the scope when a change has wider implications than the initial analysis suggests. This staged, risk-based structure is also the foundation that AI-driven test selection and prioritization build on. If you’re looking at how AI fits into this part of the pipeline specifically, see our guide, AI in Software Test Automation: 2026 Guide. 5.3 Return Actionable Results to the Workflow Test execution should produce more than a pass or fail status. Results should identify the affected scenario, provide enough evidence to investigate a failure, and remain linked to the relevant requirement, test case, code change, and execution record. Returning results to the pull or merge request helps engineering teams review automation alongside the application change. Returning them to the QA layer and requirement source gives QA teams traceability from test intent through code to execution. This closes the feedback loop and supports informed release decisions. 6. Treat Test Maintenance as a Continuous Engineering Process Flaky tests can quickly undermine confidence in an automation suite. When the same test passes and fails without a relevant application change, teams may begin treating failures as noise. Rerunning the test can unblock a pipeline temporarily, but it does not resolve the underlying problem. 6.1 Diagnose the Root Cause of Flaky Tests Flakiness can originate in the test code, application, test data, execution environment, or an external dependency. Common causes include fixed delays, missing synchronization, unstable locators, shared state between tests, conflicting test data, asynchronous application behavior, network variability, and resource constraints in the execution environment. The corrective action should match the source of the problem. Timing failures may require condition-based waits rather than longer fixed delays. Shared-state failures call for stronger isolation and controlled data setup. Selector failures may require more stable locators or reusable application abstractions. Failures caused by external dependencies may require controlled test environments, mocks, or other ways to reduce unnecessary variability. Teams should capture enough information to distinguish a product defect from a test defect or an environment failure. Execution traces, logs, screenshots, videos, network activity, environment details, and the affected test step can make intermittent failures easier to reproduce and diagnose. 6.2 Review and Prune the Test Suite Regularly Automated tests should be reviewed throughout their lifecycle. Product changes can make tests obsolete, duplicate existing coverage, or reduce their business value. Keeping every test indefinitely increases execution time and maintenance effort without necessarily improving release confidence. A defined maintenance cadence should include reviewing flaky tests, retiring obsolete scenarios, consolidating duplicate coverage, and reassessing tests whose business impact or technical stability has changed. The frequency should reflect the size of the suite, release cadence, application risk, and volume of product changes. Each test should have a clear outcome after review. It may be repaired, rewritten, moved to a more appropriate test layer, temporarily isolated with an assigned owner, or removed when it no longer provides useful evidence. 6.3 Track Execution Health and Maintenance Effort Pass rate alone does not show whether an automation suite is healthy. Teams should also monitor recurring failures, rerun frequency, execution duration, maintenance effort, obsolete tests, duplicated coverage, and the time required to identify and repair a failure. These signals help distinguish a growing automation suite from a sustainable one. Adding tests increases coverage only when the team can understand the results, maintain the assets, and trust the evidence produced by each execution. Maintenance decisions should also remain traceable. Teams need visibility into what changed, why a test was updated, how the change was reviewed, and whether the revised test still validates the original requirement. We will discuss this lifecycle-based approach in our article: Best QA Practices in Software Testing. 7. Treat Automation Code as Production Code Automation code should follow the same engineering standards as application code. Tests need clear ownership, version control, consistent repository conventions, review rules, and quality gates. Without these practices, scripts become difficult to understand, update, and trust as the application evolves. Ownership should cover both test intent and technical implementation. QA professionals can define the business scenario, expected result, and required coverage, while automation engineers or developers verify that the resulting code follows project conventions and can be maintained within the existing framework. Whether automation is written manually or generated with the help of AI tooling, it should enter the repository through a standard pull or merge request. Reviewers should be able to inspect what the test validates, how it interacts with the application, which reusable components it uses, and whether it introduces unstable dependencies or duplicated coverage. Generated tests should not remain inside a proprietary execution environment when code ownership and portability matter to the organization. Keeping automation in the client’s repository makes changes visible, reviewable, and subject to the same governance as other project assets. Teams should also define who responds when a test becomes unstable or outdated. Clear ownership prevents failed tests from remaining unresolved because QA, development, and automation teams each assume that another group is responsible. 8. Where AI Fits Into This Process AI is increasingly used alongside these practices — drafting test cases from requirements, verifying that a proposed path actually works before code is generated, and flagging tests that are likely to become unstable. Getting this right is less about the automation practices covered above and more about strategy, tooling, and governance, so we cover it separately in depth in AI in Software Test Automation: 2026 Guide. 9. Common Test Automation Mistakes to Avoid Even a technically sound automation program can lose value when teams make poor decisions about scope, ownership, and maintenance. Common mistakes include: Automating every available scenario instead of prioritizing repeatable, stable, and business-critical tests. Treating reruns as a permanent solution to flaky tests rather than investigating their root causes. Allowing obsolete and duplicated tests to remain in the suite without regular review. Selecting a platform based on feature count without evaluating integration, maintainability, deployment, code ownership, and team fit. Generating automation without first verifying that the test scenario works against the actual application. Accepting generated tests without checking whether they reflect the original requirement and intended business behavior. Keeping automation in a proprietary environment when the organization requires reviewable, portable code in its own repository. Managing test scripts outside standard version control, code review, and CI/CD quality gates. Leaving responsibility for test intent, code quality, and ongoing maintenance undefined. Avoiding these mistakes requires more than adding tools or scripts. Teams need a controlled workflow that connects requirements, test design, execution evidence, automation code, review, and maintenance. 10. How Qatana Applies These Test Automation Best Practices Qatana brings these practices together in an agentic test automation platform. It turns Jira or GitLab requirements into automation-ready test cases, verifies the proposed user path through Playwright execution, and generates standard Playwright code delivered through a pull-ready merge request. QA retains control of test intent, while engineering reviews the generated automation through the existing merge request process. Execution results remain linked to the requirement, test case, and code, providing traceability across the workflow. Qatana runs entirely on-premise and supports the organization’s selected LLM, keeping project context, generated code, and test evidence within the customer’s environment. Book a demo to see how Qatana turns requirements into execution-validated Playwright automation. 11. Frequently Asked Questions How much of my test suite should be automated? There is no universal target. Prioritize stable, repeatable, and business-critical scenarios, while keeping exploratory and judgment-based testing manual. What is the difference between a test automation strategy and a framework? A strategy defines what to automate, why, and how success will be measured. A framework is the technical structure used to build, execute, and maintain automated tests. How do I know if my automation ROI is positive? Compare the time and effort saved through automation with implementation, execution, and maintenance costs. If maintenance consistently outweighs the benefits, review the selected tests and automation approach. What’s the most common reason automation programs stall after an initial pilot? Usually a lack of ongoing ownership rather than a tooling problem. Teams automate an initial batch of tests successfully, but without a defined maintenance cadence, clear code ownership, and a repository review process, the suite accumulates flaky and obsolete tests faster than anyone repairs them, and confidence in the results erodes.
Read
ChatGPT, an Integrated LLM, an SLM or Automation? How to Choose the Right AI for Your Business Process
In 2025, 20% of enterprises in the European Union used artificial intelligence, compared with 13.5% a year earlier. In Poland, the figure was 8.4%. The most common application was analysing written language, used by 11.8% of the companies surveyed. The authors of a study published in 2026 in Organization Science described the uneven boundaries of AI capabilities as a “jagged technological frontier”: tasks of similar difficulty for humans can pose very different challenges for a model. The next step requires answering a more specific question: which form of AI fits a particular task? In an experiment involving 758 consultants, participants using GPT-4 completed 12.2% more tasks and finished them 25.1% faster on average when the tasks fell within the model’s capabilities. For a complex task beyond those capabilities, the probability of reaching the correct solution fell by 19 percentage points. The authors of the study, published in 2026 in Organization Science, called this uneven boundary of AI capabilities the “jagged technological frontier”. Effectiveness therefore depends on matching the technology to the task, data, risk and approach to verifying results. One process may be best served by an enterprise LLM assistant. Another may require an application connected to a CRM, a knowledge base and an access control system. A third may benefit from a small model running locally. Operations governed by explicit rules can be handled by code, rules engines or robotic process automation (RPA). Traditional machine learning is suitable for tasks such as forecasting and data classification. 1. LLMs and SLMs in Business: Choosing the Model, Integrations and Where Data Is Processed Terms such as “LLM”, “deployed LLM” and “closed SLM” combine several layers of technology. In a business context, it helps to separate four decisions: Way of working: does an employee interact with a ready-made assistant, or does the process start automatically? Scope of integration: does the solution work with materials supplied by the user, or does it retrieve data and perform actions in company systems? Model type: does the task require the broad capabilities of a large language model, or would a specialised SLM be sufficient? Processing location: does the model run as a cloud service, in a dedicated environment, in a private cloud, on premises or directly on a device? SLM stands for Small Language Model, which typically requires fewer computing resources. The term “closed system” needs clarification: it may refer to restricted access, an isolated environment or data processing within the organisation’s own infrastructure. A large language model can run in a private environment, while an SLM can be available through a public API. Model size alone does not determine how data is secured. 2. Six Ways to Use AI in Business Processes Approach How It Works Best Fit Key Metric Enterprise LLM assistant An employee assigns a task and checks the result in an approved environment, such as ChatGPT Business or Enterprise Analysis, drafting, summarising, developing alternatives and ad hoc work Time saved per task after accounting for review and corrections Integrated LLM or RAG application The model uses company sources, rules, permissions and integrations Repeatable processes involving documents, knowledge and data from business systems Cost per successfully resolved case AI agent The solution plans its next steps, selects tools and pursues a goal within a defined scope Multi-step processes involving exceptions and a dynamic sequence of actions Percentage of tasks completed correctly SLM A smaller model handles a narrow range of tasks in the cloud, on a company server, at the edge or on a device High task volumes, a fixed subject area, short response times and offline operation Quality compared with an LLM within a specified cost budget and p95 response time limit Private or on-premises deployment An LLM or SLM runs in a controlled environment, private cloud, company network or on a device Requirements relating to data residency, business continuity, connectivity, infrastructure or security policies Compliance with requirements, quality, availability and total cost of ownership (TCO) Rules, RPA or traditional ML The process is defined through code, conditions, a predictive model or a state machine Calculations, transactions, fixed workflows and unambiguous decisions Accuracy, repeatability and completeness of the audit trail In a mature deployment, these approaches often work together. The language model interprets a message, rules check the conditions, an application retrieves data, a person approves the action, and the transactional system records the result. 3. Which Tasks Are Suitable for ChatGPT or Another LLM Assistant? A ready-made LLM assistant supports tasks where an employee is responsible for checking and using the result. The user initiates the work, provides context, evaluates the response and decides how to use it. The output takes the form of a draft, recommendation, analysis or working document. Examples include: preparing a first draft of a report, message, presentation or article, summarising documents and correspondence, comparing several materials supplied by the user, developing questions, scenarios and alternative solutions, translating content for subsequent review, exploring data and explaining findings, organising meeting notes, drafting a procedure or action plan. This approach works well in processes where every response undergoes human review, the result can easily be corrected or withdrawn, and the task does not require automatic writes to a critical system. Wide variation in the source material and the need for language-related work further increase the usefulness of an LLM. Security depends on the approved product and its configuration. OpenAI states that data from ChatGPT Business, ChatGPT Enterprise and the API is not used to train models by default. The API data controls documentation also describes separate retention policies, including standard abuse monitoring logs and a Zero Data Retention option for eligible customers. Before using the solution, an organisation should review data classification, contractual terms, processing region, retention, administrator permissions and policies for connected applications. For more examples, see our overview of 15 ChatGPT integrations with business applications. 3.1 How Can You Measure Time Savings and the Quality of Work with an LLM? Relying solely on employee surveys can overstate the benefits. In a METR experiment, experienced developers took 19% longer to complete the tasks studied when using AI tools, yet afterwards still estimated that AI had made their work 20% faster. The study involved 16 participants and 246 real tasks in repositories they knew well, so its findings apply to that specific setting. The methodological lesson has broader relevance: actual task duration and quality need to be measured before deployment. For an LLM assistant, useful metrics include median task completion time, the proportion of outputs accepted without changes, average correction time, quality assessed against consistent criteria, frequency of use and the number of cases in which users return to their previous way of working. 4. When Should You Integrate an LLM with Company Systems, and When Should You Deploy an AI Agent? Integration becomes justified when the value of a process depends on current company data, a repeatable workflow and coordination across several systems. The model then receives controlled access to documents, a knowledge base, CRM, ERP, a ticketing system or email. The application verifies the user’s identity, controls which data is shared, defines the response format, checks results, logs actions and routes selected operations for approval. A typical integrated AI application consists of five layers: Input: a message, document, form, system event or record. Context: data retrieved in line with access permissions, often using RAG. Model: an LLM or SLM selected for the specific stage. Validation: rules, completeness checks, source verification and risk classification. Output: a response for a person, a draft record or an approved action in a system. Use cases requiring this architecture include finding answers in an internal knowledge base, reviewing contracts against a company’s risk checklist, preparing quotations using CRM data and a price list, classifying support tickets, onboarding employees, checking procurement documents and drafting responses based on customer history. RAG retrieves up-to-date passages from approved sources and adds them to the context used to generate a response. An AI agent represents a further level of integration. It receives a goal, selects tools and plans a sequence of actions. According to the current Google Cloud guidance on agentic architecture, agents are suited to open-ended, multi-step problems that require external data and a degree of autonomy. An application with a predefined sequence of steps is usually sufficient for a single summary or translation. We explore the role of an advanced model as a reasoning layer connected to tools, data and permissions in our article GPT-5.5 for Business: A New Era of AI Agents. The scope of an agent’s autonomous actions can be expanded when test results confirm the required effectiveness and safety. Its permissions should be limited to the functions needed for the process, read access should be separated from write access, and actions with significant consequences for the company or customer should require approval. OWASP identifies excessive functionality, excessive permissions and excessive autonomy as the three main causes of Excessive Agency risk. The principle of least privilege limits the consequences of misinterpretation, fabricated information or an attack that feeds malicious instructions to the model (prompt injection). 5. Which Business Processes Are Suitable for a Small Language Model (SLM)? A Small Language Model uses fewer parameters and computing resources than a large language model. According to Microsoft Azure, this can support faster responses, lower infrastructure requirements and data processing close to where the data originates (edge computing), for example on industrial devices. A specialised SLM can be suitable for tasks with a fixed subject area, predictable inputs and a clearly defined output. An SLM is worth testing when a process meets several of the following conditions: a fixed set of categories, intents, fields or response types, a high and predictable volume of requests, a requirement for a short response time measured as p95, the threshold within which 95% of responses are completed, limited hardware resources, a need to operate offline or directly on a device, access to data from the relevant business domain and a set of reference answers, the ability to escalate difficult cases to a larger model or a person. Examples include classifying support tickets into 30 fixed categories, identifying a user’s intent, extracting field values from a single document type, generating short responses within a tightly defined subject area or analysing messages locally on an industrial device. The choice depends on testing with company data. An SLM should meet the required targets for quality, response time and cost per correctly handled case. For example, a company might require the smaller model to retain at least 98% of the reference LLM’s quality score, reduce the cost per correct result by at least 20% and stay within the p95 response time limit. These are illustrative decision thresholds that the process owner sets before the pilot. 5.1 When Should You Deploy an LLM or SLM On Premises or in a Private Cloud? A private or on-premises deployment may be driven by requirements relating to data sovereignty, security policies, business continuity, network latency or operation without internet access. Such a deployment can use an SLM or a larger model. An enterprise application can also use a managed API with encryption, retention controls, an appropriate processing region and contractual provisions governing data handling. A cascading architecture can be the most effective approach. Microsoft describes a hybrid model in which an SLM handles routine queries and passes more complex cases to an LLM. In a business setting, it is worth adding a third route to this cascade: referring the case to an employee when the result is uncertain, the risk is high or required data is missing. 6. Which Processes Should You Automate with Rules, RPA or Machine Learning? Processes governed by fixed rules require a clearly defined sequence of actions and conditions for carrying them out. AWS documentation on orchestration distinguishes between rule-based workflows, where successive states and transitions are explicitly defined, and agentic orchestration, where a model interprets the goal and dynamically selects tools. Both layers can operate within a single application. Process Recommended Mechanism Role of the Language Model Calculating tax, pay or a discount Code and a rules engine Explaining the result or interpreting the user’s query Executing a payment, refund or limit change A transactional process with access controls Identifying intent and preparing data for approval Granting or revoking permissions Identity and access management (IAM), role-based rules and approvals Handling a request expressed in natural language Checking that all required fields are complete A schema validator Extracting fields from an unstructured document Predicting customer churn or forecasting demand Traditional machine learning Explaining contributing factors and drafting communications Interpreting a free-form message An LLM or SLM Classifying intent and passing data to a controlled workflow In a financial process, an LLM can read a message, identify the request and prepare a proposal. Rules check the balance, limits, customer status and required approvals. The transactional system executes the operation once the conditions are met. Each layer performs a task for which clear criteria for correctness can be defined. 7. How Do You Match AI to a Business Process? Four Assessment Criteria An initial assessment can be carried out during a short workshop. The process owner evaluates the process across four areas, assigning a score from 0 to 3 in each. The individual scores help define requirements for the model, integrations, safeguards and infrastructure. Dimension 0 1 2 3 Complexity of content interpretation Fixed fields and rules A fixed set of categories Interpreting context Combining information and reasoning across multiple sources Integration and autonomy No access to systems Reading from a single source Reading from multiple sources or preparing data to be written to a system Transactions and dynamic tool selection Impact of an error Easily reversible Limited operational cost Significant financial, legal or reputational impact Critical or irreversible consequences, or an impact on rights and safety Infrastructure and data requirements A managed cloud meets the requirements A specific region or retention policy is required A private network or strict latency limit Operation offline, in an air-gapped environment, at the edge or directly on a device The scores can be interpreted as follows: Content interpretation complexity of 0-1 with stable rules: code, workflows, RPA or traditional ML. Complexity of 2-3, integration of 0-1 and error impact of 0-1: an enterprise LLM assistant with user review. Complexity of 2-3 and integration of 2-3: an integrated LLM application, RAG or an agent. Complexity of 1-2, a narrow domain and infrastructure and data requirements of 2-3: an SLM as a candidate for comparative testing. Error impact of 2-3: approval by an authorised person, safeguards based on predefined rules and a complete activity log, regardless of model type. The table helps identify solutions for a pilot. The final decision follows a comparison of their performance on the same set of real cases. 8. ChatGPT, Integrated LLMs, SLMs and Automation: Business Use Cases Example Process Recommended Architecture Key Performance Indicator Human Oversight Drafting marketing content An enterprise LLM assistant Median time saved and percentage of outputs accepted Approval of every publication Summarising a meeting and listing action items An enterprise assistant with access to an approved source Completeness of action items and number of corrections Verification of task owners and deadlines Answering questions about internal procedures An integrated LLM with RAG and source citations Percentage of answers grounded in sources and accuracy of citations Escalation when no source is available Assigning support tickets to predefined queues An SLM or classifier, with an LLM for exceptions Macro-F1 and the proportion of priority tickets correctly identified Review of uncertain cases Reviewing contracts against a company’s risk checklist An integrated LLM with RAG, rules and logging Rates of detected and missed risky clauses Decision by a lawyer Extracting fields from a single invoice type OCR, traditional ML or an SLM, combined with rule-based validation Field-level accuracy and cost per document processed Review of exceptions Preparing a quotation using CRM data and a price list An integrated LLM, RAG and price retrieval governed by predefined rules Preparation time and percentage of quotations requiring commercial corrections Approval of pricing and terms Checking refund eligibility Process rules Compliance with policy and time to decision Handling exceptions Executing a refund A transactional workflow with authorisation 100% accounting accuracy and a complete audit trail Depends on the amount and risk Analysing machine messages locally An SLM or specialised model running at the edge p95 response time, alarm detection rate and availability without an internet connection Escalation of critical alarms Revoking access for a departing employee IAM and a deterministic workflow Completeness of access revocation Approval in line with policy Handling a customer case across multiple steps An AI agent with a restricted set of tools Task success rate, correctness of tool use and percentage of cases referred to an employee Approval checkpoints for high-impact actions 9. How Do You Measure the Results of an AI Deployment? Quality, Time and Cost Metrics Measurement starts with the existing process. The Generative AI at Work study, involving 5,179 customer support employees, found an average increase of 14% in the number of issues resolved per hour. Less experienced employees saw the greatest improvement. Productivity defined this way has a clear numerator, denominator and comparison group. An enterprise pilot requires similar precision. Area Metric How to Measure It Scale Case volume Number of cases per month, seasonality and peak demand periods Time Case handling time Mean, median and p90 before and after deployment Quality Task success rate Percentage of cases meeting all criteria for correct task completion Usefulness Percentage of outputs accepted without substantive changes Proportion of outputs accepted without changes to their substance Oversight Percentage of AI decisions changed by an employee Proportion of decisions or proposals modified by an employee Risk Critical error rate Number of critical errors per 1,000 or 10,000 cases Classification Precision, recall and F1 score Measured separately for each important class, particularly rare events RAG Consistency of responses with sources Percentage of claims supported by a cited, up-to-date source Agent Correctness of tool selection and supplied parameters Whether the correct tool was selected and valid parameters were supplied Automation Percentage of cases handled entirely automatically Proportion of cases completed without manual intervention Performance Time from task initiation to the final result p50 and p95 of end-to-end task completion time Economics Cost per successfully completed task Total cost divided by the number of correct outcomes Stability Changes in system quality over time Variation in quality by time period, language, category and user type Google Cloud identifies cost per successfully completed task as a key metric for AI agents operating in real business processes. A model that costs USD 0.10 per run and achieves a 50% success rate incurs a model invocation cost alone of USD 0.20 per correct result. Human review, retries, integrations, monitoring and the cost of errors must also be included. 10. How Do You Calculate the ROI of an LLM or SLM Deployment? The full cost of the solution should include development and integration, the model or API, infrastructure, monitoring, updates, human review, corrections and expected losses resulting from errors. Cost per successfully completed task: C_success = (development cost allocated to the period + model/API + infrastructure + monitoring + human review + corrections + expected losses from errors) / number of successfully completed tasks Annual benefit: Benefit = value of working time saved + avoided correction and error costs + additional margin + avoided SLA penalties ROI: ROI = (Benefit – TCO of the AI solution) / TCO of the AI solution × 100% Suppose a team classifies 20,000 support tickets per month. Each ticket takes an average of 4 minutes, and the fully loaded hourly labour cost is PLN 120. The monthly cost of manual classification is approximately PLN 160,000. During the pilot, 88% of the system’s outputs are accepted without correction. Reviewing each output takes an average of 45 seconds, correcting the remaining cases takes 3 minutes each, and the monthly costs of the model, infrastructure, maintenance and amortised implementation total PLN 51,000. reviewing all cases: approximately PLN 30,000, correcting 12% of cases: approximately PLN 14,400, model, infrastructure, maintenance and implementation: PLN 51,000, total process cost after deployment: approximately PLN 95,400, monthly cost reduction: approximately PLN 64,600, or 40.4%. This example illustrates the calculation method using assumed values. A financial assessment of an actual deployment must account for changes in the cost of errors, seasonality, downtime, exception handling costs and the pace of employee adoption. For a revenue-generating process, the calculation should also include changes in margin, conversion rate or customer retention. 11. How Do You Run a Measurable LLM or SLM Pilot? Establish a baseline. Measure volume, time, quality, errors, escalations and the cost of the current approach over at least one full business cycle. Prepare a test dataset. Include typical tasks, difficult and rare situations, boundary cases and deliberate attempts to mislead the system. Google Cloud recommends a custom dataset that reflects the full range of intended uses. Set thresholds before testing. Document the minimum quality, maximum cost, acceptable latency, critical error limit and escalation rules. Compare several approaches. Include the current process, a capable LLM, a smaller model and a hybrid architecture. Run the system in shadow mode. AI generates outputs alongside the existing process. Decisions and actions continue under the established rules. This helps identify errors before AI is allowed to handle live operations. Deploy the system within a limited scope. Start with proposals and approvals. Expand automated actions based on the results. Monitor performance quality. Repeat testing whenever the model, AI instructions, tools, data sources, rules or types of input material change. 11.1 How Many Test Cases Do You Need to Evaluate an LLM or SLM? For a metric expressed as a proportion, a conservative sample size at a 95% confidence level and a margin of error of +/-5 percentage points is approximately 385 independent cases. A margin of +/-3 percentage points requires approximately 1,068 cases. The representative sample should be supplemented with a separate set of critical and edge cases. For rare errors, the so-called rule of three is useful. If no critical errors occur in 300 tests, the approximate upper bound on their true probability at a 95% confidence level is still around 1%. Zero errors in 3,000 tests reduces that bound to approximately 0.1%. High-risk processes therefore require much larger datasets and tests targeting specific threats. 11.2 When Should You Complete an AI Pilot and Move into Production? Example Criteria Process Example Criteria for Moving into Production Support ticket classification Macro-F1 of at least 0.90; recall for priority tickets of at least 0.99; override rate no higher than 8%; p95 response time no longer than 2 seconds Internal knowledge base Acceptance rate of at least 85%; citation accuracy of at least 98%; no unsupported claims in the critical test set; p95 response time no longer than 8 seconds Draft quotation Median preparation time reduced by at least 30%; at least 75% of drafts accepted with minor changes; 100% of prices retrieved from an authorised source; human approval for every quotation These values illustrate how to define acceptance criteria. The process owner sets the thresholds according to the cost of errors, required quality and the organisation’s risk tolerance. 12. How Do You Match Human Oversight to AI Risk? NIST defines risk as a combination of the likelihood of an event and the scale of its consequences. This principle translates general concerns about AI into a measurable model: error frequency, the value of funds or resources at risk, the ability to reverse an action, the time needed to detect an error and the cost of correcting it. In the consolidated text of the EU AI Act, requirements for high-risk systems include continuous risk management, appropriate levels of accuracy, robustness and cybersecurity, and effective human oversight. Oversight measures should be proportionate to the risk, degree of autonomy and context of use. Testing should use predefined metrics and thresholds appropriate to the intended purpose. In business practice, this means assigning a specific person responsibility for approvals, monitoring and intervention. The interface should display sources, actions taken and the level of uncertainty, and the user must be able to stop the process. The risk of serious consequences from an error justifies restricting model permissions, adding further checks and extending shadow-mode testing. The regulatory classification should be assessed separately for the intended use and the organisation’s role. 13. How Can You Combine LLMs, SLMs and Rules in a Single Business Process? Combining several technologies allows each stage of a process to be handled appropriately. For example, an SLM identifies the topic of a customer’s request, while an LLM drafts a response using the contact history and documents retrieved through RAG. If the case involves a refund, the system checks conditions and limits against established rules, then routes the operation for execution or approval by an authorised employee. This approach combines automation with oversight of decisions that have financial consequences. At TTMS, we can help you assess where a similar solution would deliver the greatest benefit. We will start with the tasks that take up the most time: repetitive activities, searching for information or correcting errors. During a consultation, we will examine your workflows, available data and existing systems. Based on this assessment, we will recommend the technology and pilot scope, then work with you to define the expected outcomes and how to measure quality, time and costs. Ready to choose your first process to improve? Book a consultation with us about implementing AI. Sources Eurostat, 20% of EU enterprises use AI technologies, 11 December 2025. Fabrizio Dell’Acqua et al., Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of Artificial Intelligence on Knowledge Worker Productivity and Quality, Organization Science. Erik Brynjolfsson, Danielle Li, Lindsey Raymond, Generative AI at Work, NBER Working Paper 31161, 2023. Joel Becker, Nate Rush, Beth Barnes, David Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR, 10 July 2025. Microsoft Azure, What Are Small Language Models (SLMs)? Microsoft Azure, Boost processing performance by combining AI models, 8 January 2025. OpenAI, Enterprise privacy at OpenAI. Google Cloud, The KPIs that actually matter for production AI agents, 26 February 2026. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, July 2024. European Union, Regulation (EU) 2024/1689, consolidated text of 27 July 2026. OWASP GenAI Security Project, LLM06:2025 Excessive Agency, 2025. FAQ Do You Need to Run Your Own AI Model to Work with Company Data? Running your own model is one of several options. Companies can use an approved business environment, a managed API, a private cloud, dedicated infrastructure or a model running locally. The choice depends on data classification, processing location, retention, encryption, user identities, industry requirements and the agreement with the provider. For example, OpenAI states that business customer data is not used for training by default and offers additional retention controls for eligible API customers. Organisations should document the data flow for their specific configuration, as the model’s name does not describe the full security architecture. Can RAG Replace Fine-Tuning a Model on Company Data? RAG and fine-tuning address different needs. RAG retrieves current information from a controlled source when generating a response, making it well suited to knowledge bases, procedures, documentation and frequently updated content. Fine-tuning uses examples to adapt a model’s behaviour to a particular style, format or specialised task. AWS documentation comparing RAG and fine-tuning recommends starting with RAG for a question-answering system based on your own documents, particularly when up-to-date information and source references matter. Both approaches can work together when a process requires current knowledge and consistent behaviour within a specific domain. Can a Single Process Use Both an LLM and an SLM? Yes. A routing component can direct routine, clearly identified cases to an SLM and complex cases to a larger LLM. A third route passes cases to a person when the system detects missing data, low confidence or a high level of risk. Another option is to divide the process by function: an SLM classifies the document, an LLM prepares an explanation, code calculates values, and a workflow records the approved decision. This setup helps control costs and response times while retaining access to more advanced capabilities for difficult cases. How Many Examples Do You Need for an LLM or SLM Pilot? The number depends on the required measurement precision and how rare the errors are. When measuring the proportion of successful responses, a sample of approximately 385 independent cases provides an approximate margin of error of +/-5 percentage points at a 95% confidence level under conservative assumptions. A margin of +/-3 percentage points requires approximately 1,068 cases. The random sample should reflect the actual distribution of cases across languages, channels and user types, in proportion to their volumes. A separate test set should cover critical, edge and rare cases, along with attempts to manipulate the system. How Often Should You Retest an Application Built on a Language Model? A full evaluation should be run whenever the model, prompt version, tool, permissions, data source, business rules or input format changes. Production use also requires continuous monitoring of key performance indicators and regular regression testing. The frequency depends on the level of risk and how quickly the process changes. An application handling marketing content may follow a different schedule from a system supporting financial decisions. A practical approach is to run automated tests after every technical change, review trends monthly and conduct a business evaluation quarterly, with shorter cycles for high-risk applications.
ReadThe world’s largest corporations have trusted us
We hereby declare that Transition Technologies MS provides IT services on time, with high quality and in accordance with the signed agreement. We recommend TTMS as a trustworthy and reliable provider of Salesforce IT services.
TTMS has really helped us thorough the years in the field of configuration and management of protection relays with the use of various technologies. I do confirm, that the services provided by TTMS are implemented in a timely manner, in accordance with the agreement and duly.
Ready to take your business to the next level?
Let’s talk about how TTMS can help.
Michał Trojanowski
Managing Director TTMS Software UK Ltd.