Home •Blog
TTMS Blog
TTMS experts about the IT world, the latest technologies and the solutions we implement.
Sort by topics
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.
Read
How to Prepare Data for Power BI Copilot and Build a Semantic Model for AI
Copilot can speed up data analysis, visual creation and work with semantic models. It does not replace well-managed data sources, correct relationships or agreed metric definitions. If a model contains several similar sales measures, technical column names and ambiguous relationships, the AI assistant inherits the same problems that already affect report users. The difference is that a natural-language answer may sound convincing even when it relies on the wrong metric. To prepare data for Power BI Copilot, organisations need to improve model quality, provide business context and define how the data may be used. Enabling Copilot alone will not make an inconsistent model unambiguous. The model needs clear names, validated measures, a controlled data scope, appropriate permissions and a test set based on questions that users actually ask. This guide explains how to prepare Power BI data and semantic models for Copilot, how to use Prep data for AI and how to assess readiness before making the solution available to employees. It focuses on implementation and ongoing quality control. The broader capabilities of the assistant are covered in a separate TTMS article about AI and Copilot in Power BI. 1. Power BI model readiness for AI An AI-ready model allows users to ask questions in business language without knowing the technical names of tables and columns. This does not mean that Copilot knows the organisation or can discover every internal rule on its own. It can use the information provided through the model, its metadata, the AI feature configuration and the report context. The quality of this layer determines whether a question about sales is mapped to the official net revenue measure, order value or another similarly named field. Assess model readiness across five areas: the quality and freshness of source data; the accuracy and simplicity of the semantic model; unambiguous business concepts, names and measures; data security, permissions and ownership; a repeatable process for testing Copilot answers. If one of these areas is weak, refining prompts will have limited value. A user may phrase a question more precisely but still cannot know which of three margin measures is official or why one table uses the order date while another uses the invoice date. 2. Why the semantic model determines answer quality The semantic model sits between source data and the report user. It contains tables, columns, measures, relationships, formats, hierarchies and security rules. For Copilot, it is the main source of information about how data is organised and how it should be interpreted. The assistant may use the model schema, relationships, object properties, data types, formats and selected metadata. It should not be expected to infer definitions that carry a specific meaning within the organisation. If an active customer is defined as a customer who purchased something in the past 90 days, that definition should be implemented in the model and used by the official measure. Leaving several plausible interpretations increases the risk that Copilot will select the wrong one. 2.1 An example of an ambiguous model Suppose a model contains measures called Sales, Total Sales, Net Sales and Sales Adjusted. An analyst familiar with the project may understand the differences. A business user and Copilot see four plausible answers to the question, “What were sales last quarter?” The fix is not simply to add an instruction telling Copilot to choose one measure. First, the organisation should agree the official definition, give it a clear name, describe the calculation, hide technical fields and remove unused objects. An AI instruction can then clarify the context, but it should not compensate for disorder in the model. 3. Technical requirements before work begins Before redesigning the model, confirm that the environment meets Microsoft’s current requirements. Copilot availability depends on tenant settings, permissions, the workspace and the assigned capacity. Requirements can vary between Power BI Desktop, the Power BI service and individual Copilot experiences. At the time of writing, Microsoft’s documentation for Copilot in Power BI identifies requirements that include enabling the relevant tenant setting and using supported paid Fabric capacity or Power BI Premium capacity. Model authors also need the appropriate permissions for the workspace and semantic model. Prep data for AI is currently a preview feature. Before implementing it, account for current limitations, including the requirement to enable Power BI Q&A and the connection types supported in Power BI Desktop. Area What to check Why it matters Capacity Whether the workspace uses supported paid Fabric or Power BI Premium capacity Without the required capacity, some Copilot experiences may be unavailable Tenant settings Whether the administrator has enabled Copilot and Azure OpenAI based features for the relevant groups Access should be granted deliberately and in line with organisational policy Permissions Whether the author can edit the model and publish to the target workspace Model configuration requires permissions appropriate to the environment Connection type Whether the connection is supported by the feature used in Desktop or the service Support differs between tools and may change Power BI Q&A Whether Q&A is enabled for the model This is currently one of the requirements for Prep data for AI Licensing and feature requirements should not be copied into an internal procedure and treated as permanent. Microsoft continues to develop Copilot and change the availability of individual experiences. Check the latest documentation and the organisation’s tenant settings before implementation. 4. How to prepare data for Power BI Copilot Data needs to be reliable before it reaches the model. Copilot will not repair missing records, incorrect customer mappings or inconsistent currency codes. It can, however, use faulty data to generate an answer that hides the problem behind a plausible explanation. 4.1 Source data quality Start with data profiling and quality controls. Check completeness, uniqueness, consistency, freshness and compliance with business rules. These controls should be repeatable, not limited to the period before the first publication. In practice, this includes: identifying missing keys and orphaned records; checking for duplicates in dimension tables; aligning time zones, calendars, currencies and units; confirming that status values have the same meaning across systems; assigning data ownership and a process for resolving quality issues; monitoring data freshness and failed refreshes. Every official metric should have an identified source, owner, refresh frequency and calculation rule. This gives the organisation a reference value against which to test a Copilot answer, rather than judging the answer only by whether it sounds reasonable. 4.2 Names that match business language and stable definitions Technical names such as fct_sales_hdr, cust_id and rev_net_adj make the model harder for people to use and make user intent more difficult to interpret. The semantic layer should use names that match the language of the organisation, such as Sales, Customer, Net Revenue and Sales Region. Readable names alone are not enough. Margin remains ambiguous if the organisation uses margin amount, margin percentage, planned margin and adjusted margin. Each measure needs a precise name and definition. If one measure is official, the model should reflect that status through naming, its description, display folders and restricted visibility for supporting fields. 4.3 Correct data types and formats The data type tells the model whether a value is a date, number, text or category. The format controls how the value is presented, for example as currency, a percentage or a decimal. An incorrect type can prevent valid grouping and calculations, while an ambiguous format can cause users to misinterpret the result. Data categories should also be assigned where relevant, including for addresses, cities and geographic codes. The model needs to distinguish clearly between order, invoice, shipping and payment dates. A marked date table and explicit measures reduce the number of accidental interpretations. 5. A semantic model that Copilot can understand Microsoft’s tutorial on preparing a semantic model for AI recommends practices that include star schema design, clear naming and reduced complexity. This does not require every model to look the same. The goal is to make relationships, table roles and measure definitions unambiguous. 5.1 Star schema In a star schema, fact tables store events or numeric values and dimension tables provide context such as customer, product, time and region. This structure helps users and AI systems distinguish what is being measured from the dimensions used to break down the result. A complex snowflake model, numerous helper tables and several possible filter paths may be technically justified, but they make interpretation more difficult. If the physical model cannot be simplified, use the AI data schema to narrow the part exposed to Copilot. 5.2 Relationships and filter direction Relationships should reflect the actual data logic. Review their cardinality, active status and filter direction. Bidirectional relationships and multiple alternative paths can produce unexpected results, particularly when a question does not specify enough context. Document inactive relationships and special rules used by selected measures. If analysing sales by shipping date requires different logic from analysing by order date, users need to know how to phrase the question and the model should provide clearly differentiated measures. 5.3 Explicit DAX measures Explicit DAX measures place approved business logic in one location. They provide a safer basis for answers than ad hoc aggregation of numeric columns. Each measure should have a clear name, correct format, useful description and a business owner. Before making a model available to Copilot, check: whether official KPIs are implemented as measures; whether similar or duplicate names remain in the model; whether the result format matches the business meaning; whether measures work correctly across filters and aggregation levels; whether technical fields and helper measures are hidden from users; whether results have been reconciled with reference reports. 6. Prep data for AI in Power BI Prep data for AI is a collection of tools that saves configuration at semantic model level rather than on an individual report. This matters because one model can support multiple reports. A change to the AI schema or instructions may therefore affect more than one use case. Microsoft describes four elements used to prepare a model for natural-language interaction: the AI data schema, verified answers, AI instructions and descriptions. These elements do not work in exactly the same way across every Copilot experience. Test the configuration in the same experiences that users will access. Mechanism Purpose When it is particularly useful What it does not replace AI data schema Defines the subset of tables, columns and measures made available to Copilot When a model is large or contains technical fields and similar measures Data cleansing and correct relationships Verified answers Connect approved visuals to trigger phrases For frequent or ambiguous questions that need a consistent interpretation Source data testing and access controls AI instructions Provide rules, definitions and business context When the organisation uses terms whose meaning cannot be inferred from field names Official measures and an unambiguous model Descriptions Document the meaning of tables, columns and measures When an object’s name does not fully explain its use Instructions that cover rules across the domain 6.1 AI data schema The AI data schema limits the part of the model that Copilot considers when answering questions about data. Do not expose the entire schema by default. Technical tables, key fields, unused measures and objects created only to support a report increase the number of possible interpretations. A well-designed AI schema should include official dimensions, approved measures and the fields required for common analyses. Review the scope with business process owners. A schema that is too narrow will prevent valid questions from being answered, while one that is too broad may increase ambiguity. 6.2 Verified answers Verified answers connect an approved visual to defined trigger phrases. They are useful when users frequently ask about the same indicator or use several terms with a similar meaning. Consider a question about sales by area. In one organisation, area may mean a geographic region; in another, it may refer to a product group. A verified answer can direct the relevant wording to a visual that has already been checked. The underlying measure, filters and permissions still need to be tested. For each verified answer, record an owner, the supported questions, the metric source and the date of the latest review. A change to the indicator definition or report structure should trigger another validation. 6.3 AI instructions AI instructions give Copilot context that the model structure alone cannot express easily. They can explain organisational terminology, preferred measures, rules for interpreting periods and relationships between concepts. For example, an instruction may state that an active customer is one who purchased in the past 90 days and that peak season covers June to August. It should use the exact names of model objects and short, testable rules. Instructions are not a security control and do not guarantee that every rule will be followed. Microsoft notes that the language model treats them as guidance. Important financial and operational definitions should still be implemented through measures, relationships and data governance processes. 6.4 Descriptions for model objects Descriptions should explain an object’s meaning, intended use and relevant limitations. Instead of sales value, specify that the measure represents net revenue after discounts and returns, in the reporting currency and by invoice date. According to Microsoft’s current documentation, descriptions do not affect every Copilot capability in the same way. They are used in selected search and DAX query scenarios. They are still worth maintaining because they improve model documentation and prepare the model for further development of AI features. 7. Business context for Copilot A model can be technically correct and still fail to reflect the language used in the business. The sales team may use the term active customer, finance may refer to recognised revenue and operations may discuss a closed order. Each concept needs a definition and an owner. A business glossary is a useful starting point. It should include: the term and its accepted synonyms; a definition approved by the business owner; the corresponding table, column or measure in Power BI; the applicable time, currency, scope and aggregation rules; exceptions and situations in which the metric should not be used; the person responsible for approving changes. The glossary should not exist only outside Power BI. Transfer its most important information into names, descriptions, measures, AI instructions and verified answers. Otherwise, users and Copilot will continue to work with incomplete context. 8. Data security and governance Copilot makes it easier to ask questions, but the core access principle remains the same: users should only have access to the data required for their role. Review workspace and model permissions, row-level security roles, object-level security, Microsoft Entra groups and the way reports and models are shared. The control design should also reflect Microsoft’s guidance on the privacy, security and responsible use of Copilot in Microsoft Fabric. Write permissions require particular attention. In Power BI, the enforcement of row-level security depends in part on the user’s role and permissions for the model. Testing should use accounts that represent real user roles, not only an author or administrator account. Check whether object names, descriptions and report metadata reveal information that a user should not see. Microsoft’s documentation on using Copilot with semantic models states that, in Power BI Desktop, metadata from the current report page may in some situations be used as grounding data and may contain data values. A security assessment should therefore cover both the records and the descriptive layer of the model. Governance should define: who may prepare a model for AI use; who approves definitions and verified answers; which models may be marked as Approved for Copilot; how often regression tests are run; how incorrect answers are reported and analysed; when a model change requires renewed approval. 9. Testing Copilot answers A test should involve more than one sample question. Build a set of scenarios that reflects the language and needs of users. For each question, define the expected measure, filter scope, source of the reference value and acceptable presentation. Test type Example What to assess Basic question What were net sales last month Selection of the measure, period and value format Synonym Show turnover by region Whether the user’s language maps correctly to the official concept Ambiguous question Show the result for each area Whether Copilot asks for clarification or selects the approved interpretation Complex filters Sales to manufacturing customers in Poland last quarter Accuracy of all filters and relationships Permissions The same question asked by users from different regions Whether each user sees only the permitted data scope Change resilience Repeating tests after a measure or relationship changes Whether the update has degraded previously correct answers Assessment should cover the numeric result and how Copilot arrived at the answer. Where available, diagnostic information about how Copilot created an answer can help with investigation. The explanation of the mechanism is not proof that the result is correct. The approved metric and controlled data set remain the reference point. Copilot outputs are nondeterministic. The same prompt and grounding data can therefore produce different results. In some experiences, however, asking the same question within 24 hours while the model remains unchanged may return a cached answer. Testing is not intended to prove that every answer will always be identical. It should show that the model directs Copilot to the right data, common questions receive correct answers and users understand the known risks and limitations. 10. Common mistakes when preparing Power BI for AI 10.1 Enabling Copilot before cleaning up the model The team focuses on licensing and settings but does not review names, relationships and measures. Copilot is enabled on a model that analysts already found difficult to use. The result is ambiguous answers and a rapid loss of user trust. 10.2 Exposing the entire schema Every table and field is included in the AI data schema, including technical keys, helper measures and unused objects. More elements do not necessarily provide better context. In a large model, they can make it harder to select the correct field. 10.3 Treating AI instructions as a substitute for modelling The instructions attempt to explain dozens of exceptions that should be implemented in measures and model rules. Such a document is difficult to test and maintain. The more important the rule, the stronger the case for enforcing it in the model or data process rather than describing it only in natural language. 10.4 No ownership of metrics Analysts create verified answers without formal confirmation of which indicator definition is authoritative. When results differ, no one knows who can approve a change or which value should be used as the reference. 10.5 Testing only by model authors Model authors know the names and data structure, so they ask questions that fit the design. Business users rely on abbreviations, synonyms and incomplete terms. Tests need to include real questions collected from intended users. 10.6 No regression testing after changes A change to a measure definition, relationship, field name or report can affect earlier scenarios. Without regression testing, the organisation cannot know whether the model remains ready for Copilot. 11. Power BI Copilot readiness checklist [ ] We have identified owners for data, models and key metrics. [ ] Source data is subject to repeatable quality and freshness checks. [ ] Official KPIs have unambiguous definitions and explicit DAX measures. [ ] Table, column and measure names match the language used by the business. [ ] Technical, unused and supporting fields are hidden or removed from the AI scope. [ ] Data types, formats, categories and the date table are configured correctly. [ ] Relationships use the correct cardinality and do not create ambiguous filter paths. [ ] We have defined an AI data schema that includes only the required objects. [ ] Common and ambiguous questions have verified answers where appropriate. [ ] AI instructions explain terminology and rules that cannot be inferred from the model structure. [ ] Tables, columns and measures have useful descriptions. [ ] We have checked tenant settings, capacity, licensing and current feature limitations. [ ] We have tested RLS roles, permissions and model access with test user accounts. [ ] The test set covers basic questions, synonyms, ambiguity and complex filters. [ ] Copilot results are compared with approved reports or reference values. [ ] We have defined a process for reporting incorrect answers and revalidating the model. [ ] If the organisation uses the Approved for Copilot setting, which is currently in preview, the model is marked only after testing is complete. 12. Preparing the organisation to use Copilot Even a well-prepared model will not help if users do not know how to interpret the answers. Implementation should include short training, sample questions, an explanation of the data scope and rules for validating results. Make clear which scenarios provide decision support and which require review by an analyst or process owner. A pilot based on one model with a clearly defined scope is a practical starting point. It allows the team to collect user questions, assess ambiguity and build a test set before extending the feature to other areas. The pilot should have completion criteria, such as correct handling of priority scenarios, approval from metric owners and no critical permission issues. After launch, monitor usage, capacity cost, user reports and changes to Microsoft’s documentation. AI readiness requires ongoing monitoring and another round of testing after material changes. 13. Why TTMS Preparing Power BI for Copilot requires skills in data integration, semantic modelling, Power BI, Microsoft Fabric, security and user adoption. Focusing only on the Copilot interface does not address problems in data sources, transformations and business definitions. An engagement with TTMS can cover an assessment of existing model readiness, improvements to the data layer, changes to relationships and measures, and preparation of the test approach. Prep data for AI configuration should follow confirmation of the environment requirements and agreement on the scope of work. The engagement may focus on one pilot model or a programme spanning multiple domains and teams. A practical engagement may include: An inventory of data sources, models, reports and user groups. An assessment of data quality, model architecture and the risk of ambiguous answers. Agreement on official metrics and a glossary of business concepts. Semantic model optimisation and configuration of the AI data schema, verified answers and AI instructions. Functional, regression, security and performance testing. Preparation of governance rules, documentation and user materials. Model maintenance and renewed validation after changes to data or Microsoft features. The intended result is a model whose structure is clear to analysts and business users, with Copilot answers that can be assessed against approved definitions. The aim is to reduce ambiguity and establish a quality-control process. Even a well-prepared model cannot guarantee error-free generative AI output. 14. Discuss Power BI AI readiness If your organisation uses Power BI and plans to make Copilot available, start with a review of the data and semantic models. TTMS can help define the pilot scope, identify gaps and prepare a roadmap from data sources through to user testing. Contact TTMS to discuss preparing your Power BI and Microsoft Fabric environment for the secure use of AI capabilities. 15. FAQ Who should own a Power BI semantic model prepared for Copilot? A semantic model prepared for Copilot should have clearly assigned owners for data quality, KPI definitions and model maintenance. Ownership helps ensure that business terms, measures and AI configurations remain accurate as data sources, processes and reporting requirements evolve. How large should the AI data schema be? The AI data schema should include only the tables, columns and measures needed for common business questions. Exposing too many technical objects can increase ambiguity, while an overly restrictive schema may prevent Copilot from answering valid questions. Can Power BI Copilot use business terminology that does not exist in the data model? Copilot can better understand business terminology when organisations provide context through measure names, descriptions, AI instructions and verified answers. However, important business concepts should still be represented directly in the semantic model whenever possible. When should a Power BI model be revalidated for Copilot? A model should be revalidated after significant changes to data sources, KPI definitions, relationships, security settings, AI configurations or Microsoft Copilot features. Regular regression testing helps confirm that previously validated scenarios still return correct results. Is preparing a model for Copilot a one-time project? No. Copilot readiness should be treated as an ongoing governance process rather than a one-time implementation task. As data, business definitions and AI capabilities change, organisations need to review model quality, test key scenarios and update documentation on a regular basis.
Read
GPT-6 Astra in Microsoft 365 Copilot: Access, Tasks and Cowork Costs
Does your company use Copilot, and would you like to try GPT-6 Astra? OpenAI’s model is also available in Copilot Cowork. This means you can try it when working with documents, email and calendars in Microsoft’s environment. Access to Astra depends on your organisation’s licences and settings, while tasks performed in Cowork are billed based on credit usage. What does your administrator need to enable? Which tasks can you delegate to Astra in Cowork, and how are they handled in ChatGPT Work? Below, we explain access requirements, differences in working with files and billing rules. For guidance on choosing an assistant for your organisation, see our comparison of Microsoft Copilot and ChatGPT for business. 1. What Does GPT-6 Astra Bring to Copilot Cowork? Microsoft lists GPT-6 Astra among the models available in Copilot Cowork. Users select a model from the list enabled by their organisation. The default Auto setting lets Cowork choose a model for the task; a label next to the response shows which model was used. Selecting Astra applies to work within Cowork. The availability of a particular model in other Copilot features needs to be checked separately. GPT-6 Astra is another model you can assign tasks to in Cowork. Cowork itself provides the tools for finding information, creating files and taking action in Microsoft 365. Your choice of model may affect how information is analysed, the level of detail in the response and the time taken to complete the task. When evaluating Astra, check whether it handles an existing task better: whether it brings together findings more accurately, accounts for exceptions and produces a result that requires fewer revisions. Work IQ gives Cowork access to the context of your organisation’s work. When preparing a project summary, the information needed may be spread across documents, correspondence and meeting materials. Cowork can search for the organisational resources required for the task. Before trying it, check that the employee’s account has access to the relevant materials and that they include the latest decisions and updates. This determines which information Astra will use to produce its result. We discuss the model’s test results and examples of its use in our article GPT-6 Astra: Impressive Achievements and New Possibilities for Business. 2. How Can You Access Astra in Copilot Cowork? For business users, Microsoft describes Cowork as a service that requires a Microsoft 365 Copilot licence and usage-based billing for task execution. An administrator then needs to configure employee access. There are two separate settings to configure: Access to Cowork. The employee must belong to a group covered by a spending policy that includes Cowork. The administrator configures this in the Microsoft 365 admin centre under Copilot, Cost Management, Configuration. This is where they specify the users, budget and billing method. Access to models provided by OpenAI. In the Copilot settings, the administrator specifies which users can use OpenAI as a Microsoft subprocessor. Once you have access, open Cowork and select Astra from the model list. For your first task, check the model label next to the response. If an employee can see Cowork but cannot find Astra, the administrator should check the model provider settings. To make Cowork available to a specific team, the administrator must grant access to the relevant user group. A low credit limit restricts spending while still allowing employees covered by it to get started. 3. Astra in Cowork and ChatGPT Work: Differences in Task Execution Preparing a report involves finding up-to-date data, processing it and saving the result somewhere the team can access. At each stage, the tools available to the model matter. The comparison below shows how the two environments work with the materials needed for a task. Working with Materials in Copilot Cowork and ChatGPT Work Task Component Copilot Cowork ChatGPT Work Finding materials Searches Microsoft 365 resources accessible to the user, including email and files. Plugins can provide access to additional sources. Uses files provided for the task and information retrieved through enabled apps and authorised accounts. Working on documents Creates and modifies documents, spreadsheets and presentations. Output files are saved to the workspace in OneDrive or SharePoint. Creates and edits files. Transferring them to another system depends on the operations supported by the connection to that system. Files stored on the computer A file can be uploaded to the session. Cowork does not edit files directly on the user’s drive. Work in a supported desktop app can use local files once the appropriate access has been granted. Using an application through a browser The local Edge browser uses the employee’s existing sign-in. The feature must be enabled by an administrator. Access depends on the browser tool selected and the permissions granted. A cloud task requires separate authorisation to access company resources. When working through a browser, you need to consider where the task is running. Cowork supports the local browser when its web version is open in Edge. This feature is currently unavailable in the Copilot desktop app and on mobile devices. Cowork and Edge must also use the same work account. If the computer goes to sleep, actions requiring the local browser may be paused. In ChatGPT Work, the model can use shared files and applications on the computer during a local task. A task launched in the cloud runs in a separate environment. If the required materials are stored only on the employee’s drive or are accessible through a company VPN, they need to be made available to that environment through a supported method. As it works, Cowork displays the successive stages of the task. You can interrupt the session, clarify your instructions or provide missing information. Before taking significant actions, such as sending a message or scheduling a meeting, Cowork asks for approval. The additional confirmations it requests also depend on permissions granted earlier. For your first trial, choose a task for which you can clearly identify both the source materials and where the result should be saved. You can find examples of responsibilities in sales, HR, finance and other departments in our overview of 10 practical uses of Microsoft Copilot in an organisation. 4. How Much Does It Cost to Use Astra in Cowork and ChatGPT Work? Your budget needs to cover both the subscription and the use of tools to carry out tasks. For a company that already has the appropriate licences, enabling Cowork primarily means budgeting for usage charges. Below are the public prices for selected business plans. Subscription prices. Charges for task execution are explained below. Plan Monthly Price per User Terms Microsoft 365 Copilot Business EUR 18.20; currently EUR 15.60 under a promotional offer Billed annually, excluding tax. A separate qualifying Microsoft 365 licence is required. Available for up to 300 users. Microsoft 365 Copilot for enterprise EUR 26 Billed annually, excluding tax. A separate qualifying Microsoft 365 licence is required. ChatGPT Business USD 20 when billed annually or USD 25 when billed monthly A minimum of two users. Public pricing in USD; the final amount depends on factors including taxes and the market where the subscription is purchased. ChatGPT Enterprise Custom pricing Usage limits and billing are defined in the agreement. The Copilot Business promotion applies to the first year with an annual commitment and runs from 1 July to 31 December 2026. 4.1 How Are Cowork Tasks Billed? Cowork charges for factors including model usage, context retrieval, tool calls and runtime. Usage is converted into Copilot Credits; under the published pay-as-you-go pricing, one credit costs USD 0.01. One thousand credits therefore cost USD 10. The cost of an individual task depends on the number of credits consumed. The selected reasoning level also affects usage. Cowork offers Light, Medium, High, Extra High and Max settings. A higher level may increase task duration and credit consumption. For recurring work, check whether increasing this setting improves the result enough to justify the cost. 4.2 What Does Credit Usage Mean in ChatGPT Work? ChatGPT Work follows the usage limits and billing rules of the relevant plan. Under agreements based on a shared credit pool, tasks reduce the available balance. Credits already paid for under the agreement are covered by that payment. Additional charges may arise once those credits run out, if the agreement and settings allow work to continue. When comparing costs, use the same set of tasks and output requirements. Record usage, the number of retries and the extent of any revisions needed. Calculating the cost per successfully completed task shows how much you pay for a result your team can use. First, convert each service’s credit usage into a monetary amount using its own pricing. 5. What Data Protection Rules Apply to Astra in Cowork? In Copilot Cowork, Astra is provided by OpenAI as a Microsoft subprocessor. According to the documentation, this use of the model is governed by Microsoft’s terms and Data Protection Addendum, subject to specified exclusions. These services fall within the EU Data Boundary, with documented exceptions. Microsoft currently excludes them from its commitments to process data in a specific country. This detail matters to organisations that require processing exclusively in Poland, for example. When enabling Astra, the administrator should therefore consider the model provider’s policies and access to the materials used in the task. In ChatGPT Work, whether the task runs locally or in the cloud also matters. During a local task, file excerpts, screenshots and tool outputs may be sent to OpenAI. Company AI policies should account for this method of sharing information as well. 6. Which Task Should You Start with When Trying Astra? Start with a responsibility that regularly involves an employee gathering information and preparing material for other people. This workflow lets you assess both Astra’s analysis and the tools available in Cowork or Work. A weekly project summary is one example. A sample prompt for your own trial: Using the project folder [link] and correspondence about this project from the past seven days, prepare a report for the manager. List revised deadlines, pending decisions and the people responsible for next steps. Provide a source and date for each finding. If the materials contain conflicting information, show the discrepancy and explain what you need to resolve it. Save the report as a DOCX file using the attached template in the folder [link]. Draft a message to [recipients] with a link to the report. Leave sending it subject to my approval. Check whether the report reflects the latest decisions and updates, provides sources and dates, identifies conflicting information and assigns responsibilities correctly. Also assess whether it follows the template and whether the file has been saved in a folder accessible to its recipients. After a successful trial, you can consider running the task regularly. Cowork supports scheduled tasks and tasks triggered by events such as an email or a Teams post. By default, event-triggered tasks prepare actions for approval. We discuss how to design the entire process in our guide to business process automation with Copilot. 7. Prepare Your First Astra Tasks with TTMS Through our AI consulting services, we help you determine which data a task requires, which tools need to be made available and how to assess the result. We also analyse the required licences and usage billing arrangements. We combine consulting with AI solution design and the integration of business systems. TTMS was the first company in Poland to obtain accredited ISO/IEC 42001 certification for its artificial intelligence management system. The TÜV Nord Poland audit covered AI design and usage policies, including risk management and project documentation. Tell us which task you would like to delegate to Astra and which applications your team uses. Talk to TTMS about AI consulting for your business. GPT-6 Astra in Copilot Cowork: Frequently Asked Questions Does selecting Astra in Cowork change the model across all Copilot applications? The selection applies to work within Cowork. Microsoft describes a separate model selection option for this environment. To find out which model powers a particular feature in Word, Excel or Teams, check that feature’s documentation. When reviewing a Cowork task, you can see which model was used by checking the label next to the response. Will the same model give an identical response in Copilot and ChatGPT? The result may differ. The model works with the information provided by each product and uses its tools, instructions and reasoning settings. When comparing results, check which materials the model received and which actions it could perform. Only then can you meaningfully assess the differences in the outputs. Why can I see Cowork but cannot select GPT-6 Astra? Access to Cowork and access to OpenAI models are controlled by separate settings. Your administrator should confirm that your account is allowed to use models provided by OpenAI as a Microsoft subprocessor. The model list displayed in Cowork reflects the access granted by your organisation. Does a Microsoft 365 Copilot subscription cover all Cowork tasks? Cowork tasks incur additional usage-based charges. Copilot Credit consumption depends on factors including the model, information retrieval and tools used. Administrators can set spending policies for users and groups. Your budget should account for both the subscription and expected Cowork usage. Can Astra in Cowork edit a document saved on my computer? You can upload a document to a Cowork session. According to the current FAQ, the service does not open or edit files directly on your local drive. Cowork works with the materials you provide and files available in OneDrive and SharePoint. Support for the Edge browser is a separate feature. Will the same Astra model produce the same result in Cowork and ChatGPT Work? The result also depends on the available data, instructions, tools and reasoning settings. A task performed using the same model may therefore proceed differently in the two environments. Comparing results using the same materials will reveal differences in the completeness of the output and the actions performed.
Read
GPT-6 Astra: Impressive Achievements, New Opportunities for Business
OpenAI unveiled GPT-6 Astra on 3 September 2026, and early research findings and user reports show why the release is generating so much excitement. The new model solved mathematical problems that earlier GPT models and competing models failed to solve in the same test. Users have already tested GPT-6 across a range of tasks, from rebuilding a sales workflow in a CRM system and creating a detailed steam locomotive model to analysing a novel spanning more than 500 pages. What exactly has it achieved, and how can businesses put these capabilities to use? 1. GPT-6 Astra’s early achievements are impressive Early tests and user reports show how Astra handles complex tasks. These include findings from a test conducted by Epoch AI and accounts from people who put the model to work on their own projects. 1.1 Solving two previously unsolved mathematical problems Epoch AI tasked five models with solving 68 Erdős problems, giving each the same time and budget limits. Only the pre-release version of Astra solved two of them and produced solutions in a form that passed automated mathematical verification. GPT-5.6 Sol, GPT-5.5, Claude Fable 5.1 and Claude Fable 5 did not solve any of the problems in this test. Astra had already recorded other mathematical achievements. Before its release, OpenAI presented ten further results involving problems in mathematics and theoretical computer science. We covered them in our article “Astra, the future GPT-6: a new model from OpenAI?”. 1.2 A 3D steam locomotive model with 3,295 editable components Tom Krcha, a designer and creator of the AI-assisted interface design tool Pencil, gave Astra an old drawing of a steam locomotive. The task was to recreate the machine in Blender, an application for building 3D models, animations and scenes. Within a few minutes, it produced a model containing 3,295 separate objects. The wheels, axles, boiler components and other parts can be selected, moved and modified independently. Astra had to interpret a flat drawing, reconstruct the machine’s three-dimensional structure and preserve the relationships between thousands of components. According to Krcha, it did this mainly by writing Python scripts that built the geometry piece by piece. The resulting model can serve as a starting point for an animation or a game project. 1.3 Rebuilding a sales workflow directly in a CRM system Claire Vo, creator of the ChatPRD platform, gave Astra access to her customer relationship management system, or CRM. Working through Codex, the model was tasked with changing how new sales leads were handled. It had to understand the existing workflow, find the relevant settings and rebuild the rules in a visual editor. After the changes, the system automatically routed leads to Claire or Zach, inserted a link to book a meeting with the appropriate person and sent the draft message to Slack for approval. The new rules would also apply to future leads. 1.4 Adding new capabilities to a Bluetooth speaker with Astra Claire Vo also used the model to experiment with a small Divoom speaker fitted with a colour pixel display. She wanted to show her own images and messages on it. According to her account, the device had no public API, an interface that would allow other software to control it. This meant working out how to communicate with the hardware. Astra built an application that displayed drawings made with a computer mouse on the speaker’s screen. It then created a tool for controlling the speaker. The model also looked up information about the latest podcast episode and sent scrolling text and an animated graphic to the display. Vo noted that earlier attempts with other models had only allowed her to display a simple greeting. This time, she received custom software for controlling the device that she could develop further to suit her ideas. 1.5 Checking plot consistency in a novel spanning more than 500 pages Jakub Szczęsny of Antyweb gave Astra an extensive draft of his own book. The model was asked to check the chronology of events, the logic of the plot and storylines introduced in one part of the text and developed many chapters later. Analysing a manuscript of this length requires tracking the characters’ stories, the sequence of events, their motivations and the consequences of earlier decisions at the same time. Astra mapped these connections and flagged passages that needed further work, consistently checking the entire text for the specified issues. Szczęsny particularly valued its ability to connect information scattered across hundreds of pages. A similar skill is useful when reviewing contracts, project documentation and reports, where details in one section affect how others should be interpreted. 1.6 An AI agent completes the entire game Portal A creator publishing as CozyBlaze connected Astra to Portal, a spatial puzzle game in which players create passages between distant locations and use the laws of physics to overcome obstacles. The model received screenshots and information about the player character’s position and the direction they were facing. It used this information to plan moves, execute them and check the results. After approximately 23 hours and 43 minutes, including waiting time and technical interruptions, it reached the end credits. The creator developed custom controls and settings to make precise movement easier, and the game paused while the model was processing its next actions. The creator also resumed the session following service availability issues, while the agent made the gameplay decisions. Completing the game required interpreting the situation on screen, spatial awareness and hours of planning moves and checking their effects. These examples help explain the enthusiasm around Astra. The model analyses a problem, carries out successive actions and uses the results to guide what it does next. For businesses, this opens up the possibility of assigning AI more complex tasks involving information and applications. Comparisons with GPT-5.6 show where performance has improved and what those gains could mean for businesses. 2. GPT-6 Astra in business: what does better performance mean for companies? Businesses using AI also bear the cost of checking responses, correcting errors and stepping in when the model cannot finish a task. Better performance from the next generation could therefore make more tasks cost-effective to delegate to AI. Astra’s results give businesses reason to reconsider how responsibilities are divided, how existing systems are used and how much time employees spend reviewing AI output. GPT-6 Astra vs GPT-5.6 Sol: test results and their business implications Skill tested GPT-6 Astra GPT-5.6 Sol Business implications Successfully completing a task across several applications, AutomationBench 41.4% 28.77% Reason to test whether AI can handle a larger part of a process independently. Locating the correct elements on screen, ScreenSpot-Pro 92.7% 76.9% Greater precision when AI interacts with business software. Detecting bugs that require analysing several files, the more challenging CodeRabbit subset 57.1% 47.6% Better performance when analysing complex dependencies in software. The results come from different tests and measure distinct skills. AutomationBench: Zapier’s leaderboard as of 9 September 2026, with both models set to Max. ScreenSpot-Pro: OpenAI’s comparison. CodeRabbit: the more challenging subset of code reviews. The business implications are interpretations of the results; any savings need to be assessed within the company’s own process. 2.1 A broader range of tasks to delegate The more stages a task involves, the more opportunities there are for mistakes. The model needs to find information, apply the right rules, perform actions in the correct order and use the same assumptions consistently throughout. These are the demands placed on models by AutomationBench, Zapier’s benchmark for business processes. On the leaderboard dated 9 September 2026, Astra successfully completed 41.4% of tasks, compared with 28.77% for GPT-5.6 Sol, with both models using their highest reasoning setting. A task counted as successful only when all required conditions were met. That amounts to roughly 13 more successfully completed tasks out of every 100. For businesses, this is an opportunity to test whether AI can complete more stages without employee assistance. It is worth reviewing tasks where an employee repeatedly prompts the model to take the next step, supplies more data or transfers the output to another application. Each intervention takes time and reduces the benefit of automation. Astra gives businesses reason to test which of these stages it can now handle together. The 41.4% result also shows how demanding these tasks remain. The level of autonomy should be determined by the model’s performance within the company’s own process. 2.2 Automating more tasks in existing business software Companies use many applications introduced at different stages of their development. AI’s access to these resources plays a significant role in how useful it can be. When a model can navigate an application’s interface effectively, businesses can consider using it for tasks that employees currently perform through forms, buttons and menus. In ScreenSpot-Pro, a test of locating elements in screenshots, Astra achieved 92.7% accuracy, compared with 76.9% for GPT-5.6 Sol. The test covers complex applications with densely packed controls. The result measures one specific skill needed to operate software. This improvement gives businesses reason to consider automating more tasks in the applications they already use. Automation planning should include tasks that currently require employees to navigate software manually. Better interface recognition could help AI carry them out when equipped with the appropriate tools and permissions. Cost-effectiveness will depend on the success of the entire operation, including reading data, making changes and checking the result. Accurately locating a button is one requirement for completing that operation successfully. 2.3 Detecting errors that require connecting information from several places Business tasks are often difficult because of the connections between pieces of information. A change to one agreed detail can affect subsequent decisions, documents and team activities. The person responsible for the overall task needs to identify these dependencies and assess their consequences. In CodeRabbit’s evaluation, Astra’s advantage was particularly clear when detecting bugs that required examining several code files. The model detected 57.1% of labelled bugs, compared with 47.6% for GPT-5.6 Sol. Across the full evaluation, the difference was smaller: 61.3% versus 59.0%. The greatest improvement was therefore seen in the more challenging cases. For those overseeing AI adoption, this offers a useful lesson: evaluate the new generation on tasks where the earlier model missed connections between pieces of information or required extensive corrections. With simple prompts, the difference between models may be small. Materials containing exceptions, interdependent conditions and information spread across several places can reveal more about Astra’s usefulness. CodeRabbit documents this improvement in software analysis. Establishing whether similar gains apply to documentation, reports or business agreements requires testing on the company’s own materials. This is a useful way to assess the model in organisations where employees spend considerable time working out how different pieces of information affect one another. 2.4 When does better AI performance translate into savings? Even a small improvement in quality can matter when a task is repeated hundreds of times a month. If employees spend less time correcting outputs and helping AI finish tasks, the team gains time back. The scale of that benefit depends on how often errors occur, how long they take to correct and the consequences of those mistakes. Astra’s results justify reassessing applications of AI that previously proved too unreliable or required too much supervision. A company can revisit a shelved idea and test it on a set of real cases, including more difficult ones. Three measures matter in this assessment: the proportion of tasks completed correctly, employee time spent on checks and corrections, and the total cost of handling each case. These indicators help establish whether the model’s better performance benefits the team as a whole. Astra’s progress could therefore make tasks that were previously too costly to automate economically viable. Tasks that have required constant human assistance are worth testing again, particularly when they are frequent, time-consuming and have a clearly defined outcome. How can your business put GPT-6 Astra to use? Our AI consulting services help you identify the tasks where improvements would deliver the greatest business benefit and plan the implementation. At TTMS, we work with clients to analyse the process, identify the data and integrations required, and agree on how to measure results. We combine consulting with designing AI solutions and integrating them with business systems. We were the first company in Poland to obtain accredited ISO/IEC 42001 certification for our artificial intelligence management system. For clients, this confirms that our practices for risk assessment, project documentation and AI oversight have been reviewed by independent auditors. Tell us about a task you would like to improve. Together, we will explore how AI could help and where to begin. Talk to TTMS about AI consulting for your business. GPT-6 Astra in business: frequently asked questions What does GPT-6 Astra change for businesses already using AI? GPT-6 Astra gives businesses reason to test whether AI can handle a larger share of a task with less employee assistance. Comparisons with GPT-5.6 Sol show improvements in completing tasks across several applications, locating on-screen elements and analysing dependencies in code. It is therefore worth revisiting processes where the team frequently corrects outputs or guides the model step by step. The benefit comes when better performance reduces the work needed to achieve a correct result. Can GPT-6 Astra work in business systems without building a new integration? In some cases, yes, provided its environment gives Astra tools to operate a browser or computer. The model can then interact with applications through forms, menus and buttons. It needs access to the system and the appropriate permissions. Whether this approach is suitable depends on the application and the task. For frequent, repetitive operations, it is worth comparing it with an API integration, which allows software systems to exchange data directly. Which tasks are worth trying with AI again if earlier automation attempts failed? Start with tasks where the earlier model lost track of the steps, confused interface elements or missed connections between pieces of information. These are areas where the tests discussed in this article show Astra’s progress. Use the same materials and assessment criteria for the new trial, including cases that previously proved difficult. If outdated data, conflicting instructions or a lack of application access caused the original failure, those issues also need to be resolved. How can you decide what GPT-6 Astra can do independently and what needs employee approval? The level of autonomy should depend on the consequences of a mistake, whether an action can be reversed and the results of tests using company data. Drafting a document or organising a copy of a dataset allows the output to be checked before use. Sending a proposal, changing commercial terms or deleting records may require prior approval. Process instructions should clearly define when AI can proceed, when it should request a decision and when it should stop because information is missing. How can you tell whether GPT-6 Astra saves your business money after checks and corrections are included? Compare the total cost of completing the same set of tasks with and without Astra. Include data preparation, tool use, reviewing outputs, making corrections and any cases that employees have to redo. A useful measure is the cost per successfully completed task that meets the required quality standard. Base the assessment on a representative set of tasks, including exceptions. This will help establish whether the savings hold up in day-to-day work.
Read
Cybersecurity After a Data Breach. Why Backup Alone Is Not Enough
High-profile incidents involving medical data show that even information processed by specialized systems can become a target for cybercriminals. When a breach occurs, management must determine not only what data may have been exposed, but also whether the organization can maintain its most important processes and restore its IT environment safely. In August 2026, the President of Poland’s Personal Data Protection Office announced an inspection of the technical and organizational measures applied by MyDr following reports of an incident involving patient data. The authority emphasized that the exact scale of the event was not yet fully known and that the company’s risk analysis would also be examined. This qualification matters: while proceedings are ongoing, the cause of the incident and the responsibility of individual parties should not be assumed. This was not the first serious warning for the Polish market. In November 2023, Poland’s Personal Data Protection Office reported a ransomware attack accompanied by a data breach at ALAB Laboratoria. The incidents differ in method and circumstances, but they point to the same conclusion: data security cannot depend on a single product or procedure. Many companies still treat backup as their main response to cyber threats. A well-designed backup can save an organization after data has been encrypted, deleted or corrupted. It cannot reverse a breach, take stolen information away from an attacker, or replace access controls, encryption, monitoring and a prepared incident response plan. 1. A data breach and data loss are different risks A data breach means that an unauthorized person has obtained, or may have obtained, access to information. Data loss concerns information that has become unavailable, deleted, encrypted or corrupted. A single attack can cause both outcomes: criminals may copy data first, then encrypt systems and demand payment for restoring access or withholding publication. Backup primarily addresses availability and recovery. If backups are current, isolated and usable, the company can rebuild systems without relying on an attacker’s promises. A backup cannot restore the confidentiality of information that has already left the organization. Legal obligations, fraud risk, incident-handling costs and loss of customer trust remain after the breach. 1.1 Double extortion changes the role of backup In a traditional ransomware scenario, the attacker encrypted data and demanded payment for a decryption key. Increasingly, attackers copy information first and then threaten to publish or sell it. This model, known as double extortion, means that restoring systems does not end the crisis. The company may resume operations, but it still needs to determine the scope of the breach, assess the risk to individuals and business partners, and communicate in line with its legal obligations. In practice, organizations therefore need two parallel plans. The first covers system recovery and business continuity. The second addresses the confidentiality breach: preserving logs, identifying the data that was taken, preventing further access and deciding which notifications are required. Backup is essential to the first plan, but it does not replace the second. This distinction also matters under the GDPR. Article 32 of the GDPR refers, among other things, to the ability to restore the availability of personal data promptly and to regularly test the effectiveness of security measures. It also requires organizations to protect confidentiality and integrity, which calls for a broader set of safeguards than backup alone. 2. Lessons from major data breaches for businesses in Poland The first lesson concerns the value of data. Medical records, customer data, financial information, employee data and intellectual property can be used for extortion, identity theft, phishing or further attacks. An organization should know where such information is stored, who can access it and how quickly unusual downloads will be detected. The second lesson concerns dependence on suppliers. Business data is often processed in SaaS systems, cloud environments, data centers and applications maintained by third parties. Outsourcing technical operations does not remove the customer’s risk. Organizations need contractual requirements, periodic security assessments, agreed incident-reporting rules and confidence that data can also be recovered after an outage or the end of the supplier relationship. The third lesson concerns governance. Security does not begin when an attack occurs. The organization should define recovery priorities, decision-making roles, communication channels and acceptable downtime in advance. For entities covered by national laws implementing NIS2, the Directive’s business continuity measures include backup management, disaster recovery and crisis management. 3. When backup genuinely protects the business Backup delivers the greatest value when primary data or systems become unavailable. This may result from ransomware, infrastructure failure, administrator error, a faulty update, accidental deletion by an employee or damage to a cloud environment. Backup can then reduce downtime, restore services and limit irreversible information loss. The entire process must be covered, not merely one folder. Resuming operations may require databases, configurations, keys, application code, documentation, integrations, system images and information about the correct service startup sequence. A copy of the data may be insufficient if the organization does not know how to restore its dependencies. 4. How backup replication archiving and disaster recovery differ These terms are sometimes used interchangeably even though they address different needs. Backup creates recovery points from which an earlier version of data can be restored. Replication maintains a second, near-current copy of an environment, but it may immediately reproduce a deleted file, an incorrect change or encryption. Archiving supports long-term information retention rather than the rapid restoration of an entire process. Disaster recovery includes the technology and procedures required to restore services after a serious event. It defines the system startup sequence, dependencies, replacement resources, team responsibilities and the method for confirming that the process works correctly. A company can therefore hold many file copies without having a viable plan for restoring operations. A mature strategy combines these mechanisms. Replication can reduce downtime after an infrastructure failure, backup enables recovery to a point before an attack, archiving supports retention, and disaster recovery organizes how all these resources are used during a crisis. 4.1 Define RPO and RTO in business terms The recovery point objective, or RPO, defines the maximum amount of recently recorded data the organization can afford to lose. The recovery time objective, or RTO, specifies how long a process may remain unavailable. These values should not be determined solely by technical capabilities. They must reflect business consequences such as halted production, interrupted customer service, delayed settlements, missed deadlines or risks to human safety. 4.2 Example of a sales system and a monthly archive If a system accepts orders around the clock, losing the most recent 24 hours of data may require hundreds of transactions to be reconstructed manually. Such a process may need an RPO measured in minutes and an RTO measured in hours. Much higher values may be acceptable for a closed archive of documents from the previous year. Applying one backup policy to both resources leads either to excessive cost or inadequate protection. 5. Why backup alone cannot stop a data breach Backup is a recovery mechanism, not a complete information-protection system. Even a perfectly restored database remains compromised if the attacker copied its contents beforehand. Backups must therefore form part of an architecture that covers prevention, detection, response and operational recovery. Access controls and the principle of least privilege limit the number of people and accounts able to download data. MFA, segmentation and separate administrative accounts make it harder to compromise an entire environment with one set of credentials. Encryption protects data at rest and in transit when the keys are managed separately and securely. DLP, information classification and monitoring help detect unusual transfers or bulk file downloads. EDR, malware protection and vulnerability management reduce the likelihood that an attacker can maintain access. An incident response plan defines who isolates systems, preserves evidence, assesses risk and initiates crisis communications. 6. How to build resilient backups with the 3-2-1-1-0 rule The 3-2-1 rule is a useful starting point: three copies of the data, two different media types or environments, and one copy outside the primary location. For ransomware resilience, it can be extended to the 3-2-1-1-0 model. The additional one represents an offline or immutable copy, while zero means no errors detected during recovery testing. Identify the data, systems and configurations that are critical to the organization’s operations. Separate the backup infrastructure from the production environment, domain and primary administrator accounts. Use offline copies or immutability controls that prevent data from being deleted or overwritten for a defined period. Encrypt backups and control access to encryption keys, the management console and emergency procedures. Monitor failed jobs, retention changes, deleted recovery points and unusual sign-in activity. Test recovery regularly in an isolated environment and document the RPO and RTO achieved. CISA’s ransomware guidance recommends maintaining encrypted, offline backups and regularly checking their availability and integrity. Ransomware often attempts to find and delete accessible backups, so logical separation and immutability matter as much as backup frequency. 7. An untested backup is only an assumption A successful backup job does not prove that the organization can resume operations. A backup may be incomplete, corrupted, infected, dependent on an unavailable key or impossible to run on the available infrastructure. The problem may only become apparent during a crisis, when the team has the least time and capacity to respond. Testing should cover more than the recovery of one file. It should restore a representative process and verify the service startup sequence, integrations, permissions, data integrity and users’ ability to work. The exercise should end with a report stating what was restored, how long it took, what data was lost and which corrective actions are required. A mature organization also plans for some personnel and primary communication tools to be unavailable. Emergency instructions, contact details, keys and minimum configurations should remain securely accessible outside the environment affected by the incident. 8. The first 24 hours after an incident Initial actions affect both system recovery and the later investigation. Hastily deleting files, restarting servers or immediately restoring the entire environment can destroy evidence needed for analysis and reactivate the attack mechanism. Contain the incident. Isolate affected systems and accounts in accordance with the prepared procedure while preserving material required for analysis. Preserve evidence and determine the scope. Retain logs, identify affected systems and establish whether the event caused only unavailability or also involved data exfiltration. Protect the recovery environment. Before restoring data, confirm that backups are intact and that the accounts, vulnerabilities or configurations used in the attack have been secured. Activate decision-making and communication procedures. Involve the people responsible for IT, security, data protection, legal matters, business continuity and customer communications. Recovery should follow business priorities rather than an arbitrary server order. Restore foundational services and security controls first, followed by the processes with the greatest impact on customers, revenue, legal obligations or operational safety. 9. Supplier security as part of corporate cybersecurity If a supplier stores or processes data, the backup assessment should reflect the shared-responsibility model. The customer needs to establish who creates the backups, where they are stored, how long recovery takes, whether an export is available and what happens to the data when the contract ends. Saying that a service runs in the cloud does not answer these questions. The contract should define incident-reporting rules, cooperation during breach analysis, log retention, support for regulatory requests and notifications to affected individuals. Organizations should also verify subcontractors, data locations, privileged access and business continuity test results. A supplier certificate or declaration can support the assessment, but it does not replace an analysis of the specific service and its data flows. 9.1 Why a SaaS provider may not deliver complete backup coverage In SaaS services, the provider usually maintains platform availability, but the customer may remain responsible for retention, configuration, user accounts and the recovery of accidentally deleted information. Version history or an application’s recycle bin does not necessarily provide the required change history, an isolated copy or an export capable of restoring the process outside the service. Before purchasing a service, verify the division of responsibilities, the retention period for deleted data, bulk recovery options, protection against administrator account takeover and the method for recovering data during an extended provider outage. 10. Building cyber resilience beyond backup Cyber resilience is the ability to prevent incidents, detect them, contain their effects and restore operations. Backup addresses only part of this cycle. Its effectiveness depends on accurate inventories, data classification, access management, monitoring and prepared personnel. A practical starting point for management is a set of questions. Do we know where our most important data is stored? Do we have an immutable copy? When did we last restore a critical process? Who decides whether systems should be isolated? How do we communicate with customers and authorities? Can our suppliers provide evidence that their procedures work? Any unanswered question identifies an area that requires prompt attention. 10.1 A short organizational checklist The most important data and processes have assigned owners, RPOs, RTOs and a defined recovery order. At least one copy is isolated, offline or immutable, and protected with credentials that differ from those used in production. Tests cover the entire business process, not merely the recovery of one file. Monitoring detects failed jobs, retention changes, backup deletion and unusual administrator activity. Supplier contracts govern data recovery, cooperation during incidents and service termination. The incident response plan identifies decision makers, communication channels and the way technical, legal and business functions work together. 11. How TTMS helps organizations prepare for incidents TTMS helps organizations assess safeguards, develop security policies, protect data, and prepare incident response and business continuity procedures. Support may include cybersecurity audits, encryption, DLP, malware protection, vulnerability management, incident response and disaster recovery planning. This approach places backup within a broader security strategy. The objective is to confirm that the most important processes can be restored within the required time and that consistent technical and organizational measures reduce the risk of a data breach. Can your organization do more than create backups and restore its data and critical processes securely? Explore TTMS cybersecurity services and prepare your business before an incident occurs. FAQ Does backup protect a company from a data breach? No. Backup helps recover data after deletion, encryption or corruption, but it does not prevent an unauthorized person from copying it. Preventing data breaches requires access controls, encryption, DLP, monitoring and incident response, among other measures. How often should a company test data recovery? The frequency should reflect the risk and importance of the process. Critical systems require more frequent testing than archives with little operational impact. Testing should also be repeated after a material change to the infrastructure, application, supplier or backup policy. Is cloud backup sufficient? It can form part of an effective strategy, but storage in the cloud does not by itself guarantee resilience. Organizations should verify account separation, versioning, immutability, encryption, retention, export options and the response to losing access to the primary account or provider. Is the 3-2-1-1-0 rule a legal requirement? No. It is not a universal legal requirement for every company. It is a practical model for designing backups that are resilient to failures and ransomware. The specific measures should reflect the risk assessment, type of data, applicable regulations, contractual obligations and required level of business continuity. Where should an organization begin its resilience assessment? Begin by inventorying critical data and services, defining RPO and RTO, reviewing access rights and testing the recovery of a selected process. The findings should lead to an action plan covering technology, procedures, suppliers and named responsibilities.
Read
Limitations of AI in Legal Software: Risks of Incorrect Advice, Defective Court Filings and Missed Deadlines
An authentic case number supporting a fabricated proposition is one of the most dangerous forms of legal hallucination. In June 2026, Poland’s Supreme Administrative Court described a submission in which counsel cited three judgments that genuinely existed. The problem was that they concerned different legal issues and did not contain the propositions attributed to them. The submission appeared credible until someone checked the original sources. This example illustrates the practical limitations of AI in legal software. An error may affect legal arguments, the assessment of evidence, deadline calculations, advice given to a client or the content of a court filing. The lawyer who approves the advice, opinion or filing remains responsible for its final content. Any potential liability for damages is assessed by reference to the applicable professional standard of care, the scope of the engagement and the circumstances of the individual case. In this article, you will learn about: the most common AI errors in legal work, hallucinations involving legislation, judgments and case numbers, the procedural consequences of using incorrect AI-generated content in a court filing, a lawyer’s liability for advice prepared with the assistance of AI, principles for the safe implementation of AI software in a law firm. For a broader discussion of compliance, confidentiality, providers and risk classification, see AI for lawyers in Europe and the UK: key risks and limitations. Here, we focus on what may go wrong in a specific case governed by Polish law and how to design a process that helps identify errors before legal advice or a court filing is sent. An authentic case number and a fabricated proposition: lessons from the Supreme Administrative Court’s order in case I FZ 104/26 In its order of 23 June 2026 in case I FZ 104/26, the Supreme Administrative Court considered an appeal against an order refusing to stay the enforcement of a tax decision. The appellant was required to substantiate the conditions set out in Article 61 § 3 of the Law on Proceedings before Administrative Courts, particularly the risk of substantial damage or consequences that would be difficult to reverse. Counsel cited three judgments together with propositions purportedly drawn from them. The Court found that the judgments concerned different issues and that their written reasons did not contain the propositions attributed to them. The dates given for those judgments were also incorrect. The Supreme Administrative Court identified another issue: the submission was general in nature and did not contain specific data or documents that would have allowed the Court to assess the party’s financial position. The appeal was dismissed. The Court criticised counsel’s uncritical use of AI and emphasised that a client is entitled to expect professional service. The decision illustrates three practical consequences of a defective workflow: a legal argument may lose the support of the source on which it purports to rely, a submission may omit facts and evidence that are material to the outcome, the court may question the reliability of counsel’s work. A proper verification of a judgment includes checking the court, date, case number and type of decision, followed by reading the full written reasons. The lawyer should assess the factual context, legal basis, significance of the cited passage, available information about the decision’s finality and subsequent case law concerning the same issue. Seven AI limitations that may affect the outcome of a case 1. A genuine source may be cited in support of a fabricated proposition A model may provide a genuine case number, a provision of legislation or the title of a publication and then attribute content to that source which it does not contain. This type of error is more dangerous than an entirely fabricated case number because it may remain undetected during a cursory review. The system should take the user directly to the relevant passage in the source. Verification by a lawyer remains necessary. A Stanford RegLab study of US legal research tools combining database searches with generated answers found hallucinations in 17-33% of responses. The study covered products and questions from the US market, so it does not measure the quality of Polish systems. Connecting a model to a legal database reduces the risk. Further safeguards are required to verify the accuracy of its output. 2. The model may apply an outdated or inapplicable provision An answer may sound plausible while relying on a provision that has been amended, has not yet entered into force or applies in another jurisdiction. In a cross-border matter, the model may confuse the applicable law, jurisdiction and procedural rules. An AI system for lawyers should identify the applicable legal system and the date as of which the law has been verified for each conclusion. The user should be able to see the version of the legislation, the date on which an amendment entered into force and the relevant official source. A label stating that the information is “up to date” has limited value unless the interface also indicates when and on what basis its currency was verified. 3. The model analyses only the case materials made available to it The case file may be incomplete, an attachment may not have been read correctly, or a material fact may be contained in a table, scan or message that was not included in the analysis. The model formulates its answer on the basis of the materials it has received and has no knowledge of documents that were not submitted for analysis. As a result, a confident answer may be based on an incomplete picture of the case. Before starting the analysis, the system should display a list of the files used, any processing errors and the scope of any omitted material. In matters requiring findings of fact, it is useful to provide a separate summary of assertions, supporting evidence and missing materials. This allows the lawyer to identify conclusions reached without access to a key document. 4. Calculating procedural deadlines requires clearly defined rules The calculation of a deadline depends on factors including the type of proceedings, the method of service, the date of the relevant event, transitional provisions, public holidays and exceptions applicable to the specific procedural step. A language model may overlook one of these conditions or misread a date from a scanned document. Procedural deadlines should be calculated using a controlled, rules-based mechanism with clearly stated input data. A model may extract dates from documents and suggest their legal significance. The final calculation should identify the legal basis, show how the deadline was calculated and be approved by the lawyer handling the case. Deadlines whose expiry may produce procedural consequences require an independent calculation and a second verification. 5. Factual assertions in an AI-assisted court filing require appropriate evidence According to press reports discussing the judgment of the Regional Court in Wrocław of 27 November 2025 in case X GC 455/25, the claimant used ChatGPT when preparing the statement of claim. The claim was dismissed because the formal conditions of the request for proposals had not been satisfied. The Court also addressed the AI-generated content and the evidential value of the materials submitted. Printouts containing generated arguments, legal analysis and an assessment of the prospects of success did not constitute evidence of facts material to the determination of the case. They could be treated as part of the claimant’s legal argument. A legal AI system should clearly distinguish between factual assertions, legal grounds and evidence. A missing contract, item of correspondence, proof of service or financial document remains an evidential gap regardless of the quality of the generated reasoning. 6. The model may reinforce the client’s assessment of the case Clients often describe a dispute from one perspective and expect confirmation of their own assessment. A model may adopt the client’s assumptions and overlook the other party’s arguments. This creates a risk that the client will make a decision without understanding the weaknesses of the case. The analysis should consider the opposing party’s perspective, including missing facts, potential counterarguments, procedural obstacles, alternative legal characterisations and the level of uncertainty. In client-facing communications, users should be able to refer a question to a lawyer, particularly when it concerns a deadline, a legal claim, criminal liability, termination of employment or a significant financial decision. 7. A convincing style may conceal errors and uncertainty A model generates an answer word by word and may maintain the same professional tone when presenting both correct and incorrect conclusions. Assessing reliability on the basis of style is therefore unsafe. A confidence score expressed as a percentage may also create a false impression of precision if it has not been calibrated for the specific use case. A well-designed system identifies its sources, missing information, conditions that could change the answer and situations in which it cannot provide a definitive conclusion. It should also be able to decline to answer and refer the matter to a lawyer. Can a client claim that AI caused them to lose the case? A client may raise such an allegation. The assessment of liability will depend on how the legal service was performed and on the circumstances of the individual case. In a contractual relationship, the primary rules are those set out in the Polish Civil Code. Under Article 355 § 2 of the Civil Code, the professional nature of the debtor’s activity must be taken into account when assessing due care. Article 471 of the Civil Code sets out the rules governing liability for non-performance or improper performance of an obligation. An adverse outcome does not in itself establish that a legal services agreement was performed improperly. The assessment covers compliance with the applicable professional standard of care, the correct determination of the factual and legal position, and the appropriateness of the actions taken. In a contractual liability dispute, the client should demonstrate: the existence and terms of the obligation, non-performance or improper performance of the obligation, the loss suffered, an adequate causal link between the breach and the loss. Article 471 of the Civil Code establishes a presumption that non-performance or improper performance of an obligation results from circumstances for which the debtor is responsible. Whether the debtor can avoid liability must be assessed in light of the circumstances of the individual case. The assessment may be affected by how AI was used, particularly whether the sources were verified, the complete case file was considered, the current law was applied and control over the final content of the advice was retained. A system failure or an error attributable to the provider will be assessed together with the choice of tool, the contractual terms, the scope of testing performed and the lawyer’s method of verifying the output. Examples include: missing a deadline because the date of service was determined incorrectly, advising against pursuing a legal remedy on the basis of an outdated provision, filing a submission containing a quotation that does not appear in the cited judgment, recommending a settlement on the basis of an incomplete case file or an incorrect calculation of the financial consequences, a chatbot giving the client a definitive answer without referring the matter to a lawyer. These examples are illustrative. Any assessment of liability requires an examination of the scope of the engagement, the applicable standard of professional care, the loss suffered and the causal link. The conditions for disciplinary liability may be assessed separately. The Polish Law on the Bar and the Polish Act on Attorneys-at-Law also require advocates and attorneys-at-law to hold professional liability insurance. Compulsory professional liability insurance does not necessarily cover every loss connected with the use of AI. The insurer’s liability depends on the terms of the policy and the circumstances of the individual event. What procedural consequences may result from an incorrect AI-assisted court filing? The consequences depend on the type of defect and the applicable procedural rules. An error resulting from the use of AI is assessed in the same way as any other error in a court filing. Its significance depends on how it affects compliance with formal requirements, proof of the relevant facts, the legal and factual basis of the relief sought, and compliance with applicable deadlines. Depending on the type of defect, the consequences may include: the return of a filing if its formal defects have not been remedied, the rejection of a statement of claim, appeal or other means of challenge where the conditions specified in the applicable procedural rules are met, the court disregarding an application for evidence or the evidence itself, a finding that a material fact has not been proven, the court declining to accept an argument based on a source that does not support the proposition attributed to it, the dismissal of an application, appeal or claim because the required conditions have not been established, an order requiring the party to pay the costs of the proceedings or the imposition of a procedural sanction where provided for by the applicable rules. In case I FZ 104/26, the Supreme Administrative Court dismissed the appeal because the appellant had failed to substantiate the conditions for staying the enforcement of the decision under Article 61 § 3 of the Law on Proceedings before Administrative Courts. The general nature of the arguments and the absence of supporting documents were relevant to this assessment. The incorrect references to case law were an additional factor in the Court’s critical assessment of how the submission had been prepared. Any claim for damages against counsel is considered in separate proceedings. Disciplinary liability is assessed by the competent bodies of the relevant professional organisation. What follows from professional rules and the AI Act in 2026? On 15 June 2026, the Polish Bar Council announced the adoption of a resolution amending the Code of Ethics for Advocates and Dignity of the Profession by adding § 23e. According to the information published by the Polish Bar Council, technological tools should serve an auxiliary function. Their use must respect professional secrecy, the advocate’s independence and the advocate’s personal role in handling the case. The output produced by such a tool must be independently assessed and verified by the advocate. For attorneys-at-law, relevant points of reference include the recommendations on the use of AI published by the Polish National Bar Council of Attorneys-at-Law. These practical guidelines address professional responsibility, confidentiality, output verification and human oversight. At EU level, Article 4 of the AI Act has applied since 2 February 2025. It requires providers and deployers of AI systems to take measures supporting the development of AI literacy among their personnel. The measures selected should take account of the personnel’s technical knowledge, experience, education and training, as well as the context in which the system is used and the people in relation to whom it is intended to be used. The European Commission explains that the appropriate way to fulfil this obligation depends on the organisation’s role and the risks associated with the specific use of AI. Since 2 August 2026, the competent authorities have been responsible for supervising compliance with this obligation. The classification of an AI system depends on its intended purpose. High-risk systems may include solutions intended to be used by, or on behalf of, a judicial authority to assist that authority in researching and interpreting facts and law and in applying the law to a specific set of facts. The assessment covers the system’s actual function, the intended purpose specified by the provider and the way in which the deployer uses it. Law firm tools used to search documents, draft text or prepare summaries require an individual classification assessment. The fact that a system is used by a law firm or legal department does not in itself place it in the high-risk category. Following the amendments adopted in 2026, the obligations concerning systems listed in Annex III are due to apply from 2 December 2027. Depending on the system’s function, the type of data involved and the way in which it is used, the GDPR, rules protecting professional secrecy, the applicable procedural rules, and civil and disciplinary liability rules may also apply. How should an AI system for lawyers be designed to reduce risk? A properly designed implementation should make it easier to identify errors, limit their effect on the matter being handled and document completion of the required review. Risk Control built into the product or process Review record Fabricated proposition or quotation A link to the full source and the specific passage, a contextual preview, and mandatory approval before export Court, date, case number, type of decision, source, document version and approving reviewer Outdated law Jurisdiction and date metadata, version control for legislation, and notifications of amendments Date as of which the law was verified and the version of the provision used Incomplete case file A list of analysed files, OCR error notifications and an inventory of missing data Document inventory and file processing report Incorrect deadline calculation A mechanism based on defined rules, clearly stated input data and a second human review Legal basis, input data, calculation method and approving reviewer Overly definitive advice Questions about missing facts, escalation criteria and the ability to decline to provide an answer Reason for escalation and details of the follow-up action taken Disclosure of information protected by professional secrecy Case-level permissions, controls over access by the provider and its subprocessors, a defined processing location, data retention and deletion rules, and exclusion of client data from model training Access logs, provider configuration, retention period, information about subprocessors and incident records Changes in quality following a system update Testing on representative matters before deployment and after any change of model Test results, model version and the decision approving the new version for use The scope of documentation should be proportionate to the risk. Audit logs, including the history of prompts and outputs, may contain information protected by professional secrecy. The organisation should define which data is recorded, who is authorised to access it, how long it is retained, how it is deleted and how the logs are secured. The full history of interactions with the system need not be retained where a narrower set of information is sufficient to demonstrate that the required review was performed. Natalia Lener-Bobek, a partner at Sawaryn i Partnerzy law firm, returns to the example discussed earlier of a court filing containing incorrect references to case law. She highlights decisions made before work with AI begins: the choice of tool and the terms of the contract with its provider. “This example illustrates user error. The risk arises earlier, when the tool itself is selected. Law firms check whether the model provides good answers and overlook the contract governing their use of it. The record of prompts and outputs discussed in this article exists only if the provider has undertaken to maintain it and make it available on request. This is a contractual commitment, not a feature that can be taken for granted. Before implementation, I check three things with my clients: whether the contract specifies who is liable for incorrect system output, whether the provider guarantees access to query logs for long enough to defend against a potential claim, and whether the processing terms permit information protected by professional secrecy to be entered into the tool at all. Without answers to these three questions, the staff training obligation under Article 4 of the AI Act has no practical foundation.” Natalia Lener-Bobek Partner at Sawaryn i Partnerzy law firm A safe allocation of tasks between AI and the lawyer Tasks should be assigned according to the potential harm and how easily an error can be detected. Task Role of AI Required review Summarising a long document Preparing a working summary with references to the relevant pages Reviewing the passages material to the decision Comparing versions of a contract Identifying and organising changes Assessment of their legal significance by a lawyer Case law research and analysis Identifying potentially relevant judgments and extracting the relevant passages Reading the full judgment and assessing its factual and legal context Court filing Preparing a draft structure, editing the text and checking consistency Full verification of the facts, evidence, relief sought, legal grounds and attachments Procedural deadline Extracting dates and identifying potentially applicable calculation rules Determining the event that starts the time limit, the legal basis, the calculation method and the consequences of missing the deadline Substantive-law time limit Organising dates and identifying provisions requiring analysis Determining the nature of the time limit, when it begins and ends, and the consequences of its expiry Limitation period Organising events that may affect the running of the limitation period Assessing when the period begins, whether it has been suspended or interrupted, and when it expires Final advice to the client Preparing working materials and alternative analyses The lawyer’s personal assessment, approval and communication of the advice This approach is consistent with the practical direction set out by the CCBE in its guide for lawyers: lawyers remain responsible for their work, advice and representations, and generative AI output must be reviewed before it is used. A safe AI implementation in a law firm begins with process analysis The first step is to identify where AI-generated output may affect advice given to a client, a court filing, the assessment of a document or the calculation of a deadline. This provides the basis for defining the appropriate data sources, access permissions, verification rules and the people responsible for approving the output. If you are planning to use AI to analyse case files, work with documents or prepare contracts, explore the AI4Legal solution. We help law firms and legal departments design tools tailored to their workflows, security requirements and the scope of lawyers’ professional responsibilities. Sources Supreme Administrative Court, order of 23 June 2026, I FZ 104/26. Law on Proceedings before Administrative Courts, consolidated text, Journal of Laws of 2026, item 143. Polish Civil Code, consolidated text. Polish Law on the Bar, consolidated text. Polish Act on Attorneys-at-Law, consolidated text. Polish Bar Council, amendments to the professional ethics rules concerning AI, 15 June 2026. Polish National Bar Council of Attorneys-at-Law, recommendations on the use of AI. CCBE, Guide on the Use of Generative AI for Lawyers, 2 October 2025. European Commission, AI Act regulatory framework and guidance on AI literacy. Regulation (EU) 2026/1744 amending the timeline for the application of certain provisions of the AI Act. Stanford RegLab, Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools. Dziennik Gazeta Prawna, discussion of the judgment of the Regional Court in Wrocław in case X GC 455/25, 7 January 2026. Dziennik Gazeta Prawna, interview concerning the grounds for dismissing the claim in case X GC 455/25. Law and sources current as of 1 September 2026. This material is provided for informational purposes and does not constitute legal advice. FAQ: limitations of AI in legal software Can a client claim damages if incorrect legal advice was produced using AI? Such a claim may be possible. Liability will depend on whether the legal service was performed with due professional care, whether the client suffered loss and whether there is a causal link between the breach and the loss. The assessment may also cover the lawyer’s professional standard of care, including how the AI-generated output was reviewed and verified. Will a court reject a filing solely because it was prepared using AI? There is no general rule under Polish law requiring a court to reject a filing for this reason. The court assesses compliance with formal requirements, applicable deadlines, legal arguments and evidence under the relevant procedural rules. Incorrect citations, insufficient evidence or a defective claim may, however, lead to the procedural consequences ordinarily associated with those deficiencies. Can AI manage procedural deadlines on its own? For critical deadlines, AI should operate as part of a broader workflow that includes controlled rules and human approval. A safer process uses verified calculation rules, clearly stated input dates, the relevant legal basis, human approval and an independent reminder. How can you verify whether a judgment actually supports a proposition generated by AI? Open the full judgment in an official or reliable legal database, locate the cited passage, read it in context and verify the date, judicial panel, type of ruling and applicable law. A correct case number and court name do not establish that the judgment supports the proposition attributed to it. Must every AI prompt and response be retained in the case file? There is no single general requirement to retain the full history of every interaction with an AI system. The appropriate scope of documentation should reflect the level of risk, the law firm’s internal policies, professional secrecy, data protection requirements and audit needs. In higher-stakes matters, it is advisable to retain the sources used, the system version, the scope of human review and the identity of the person who approved the output.
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.
Sunshine Ang Sen Shuen
Sales Manager